Kubernetes mehre fragen

[Milchbroetchen]

Hallo Zusammen,
ich hab nun ein Kubernetes Cluster bestehend aus
- Master Plane Server
- 4 Weitere Nodes hinzugefügt
- Alle Server sind auch an ein Internes LAN angeschlossen (ens10, 10.98.0.0/16) und jeweils eine öffentliche IPv4 (ens3)
- Flannel wurde Installiert für die Netzwerk Kommunikation (https://github.com/flannel-io/flannel)
- Hetzner CSI Driver wurde ebenfalls installiert, um externe Volumes nutzen zu können. (https://github.com/hetznercloud/csi-driver)

Nun zu meinen fragen, es soll demnächst eine etwas größere Webanwendung drauf laufen die unter anderem mit folgenden Technologien entwickelt werden soll (Angular, NodeJS, GO, HTML, CSS) auf einer eigens gehorteten Gitlab Infrastruktur. Hat jemand von euch GitLab Runner über Kubernetes am laufen, ich habe gesehen diesen muss ich über Helm installieren und kann mir dort Tipps und tricks nennen wie ich das umsetzen kann? Dann sollen die Anwendungen ja demnächst auch über Kubernetes laufen, wie würdet Ihr das realisieren? Ich hatte an 1-2 Loadbalancer gedacht die ich vor das Cluster setze und ebenfalls mit in das Lan Netzwerk packe, dazu hatte ich überlegt auf Haproxy zurück zu greifen? Ich hatte aber auch noch was davon gelesen das Nginx oder Ingress (habe ich noch nie von gehört bzw. mit gerabeitet) eher dazu geeignet sind? Zu guter letzt möchte ich gerne auch Kunden anbieten dieses bzw. ein anderes Cluster nutzen zu können für deren Anwendungen, gibt es da eine Möglichkeit dieses abzusichern, sowie Kunden Rollen zuzuweisen damit diese eingeschränkt sind und keinen Schabernack treiben können bzw. wie ich ein solches Cluster generell vernünftig absichern könnte?

Hat von euch jemand ein Kubernetes Cluster am laufen und kann von seinen Erfahrungen berichten und ggf. Tipps geben? Wozu habt Ihr euer Cluster, welche Module könnt Ihr empfehlen die man unbedingt installieren sollte etc.

Besten Dank!

Gruß
Ich

 

[d4f]

Vorweg ein Kommentar zu deiner Infrastruktur; für Produktivbetrieb sollte man keinen Single-Master fahren. Falls der Master gestört ist verlierst du das Scheduling über alle Worker-Nodes und wenn er beschädigt ist, heißt es "Restore from Backup" für ETCD mit Crash aller laufenden Container. Um StarWars zu paraphrasieren; „Immer zu dritt sie sind. Keiner mehr, keiner weniger… Ein Leader und zwei Follower."
Theoretisch kannst du beliebig viele oder wenige Master haben, für Redundanz der Komposenten und Quorum soll es aber immer ungerade sein. Kubernetes-ETCD ist darauf ausgelegt auf 3 Nodes zu laufen.

Falls du sehr wenig Scheduling und API-Aktivität (insbesondere ETCD-Aktivität, also ConfigMaps, Secrets, Redeployments, ...) hast und mit einem abgespeckten Kubernetes Ressourcen sparen willst, kannst du auch einen Blick auf K3S werfen. Hochskalierbar auf zig Worker und tausende Pods ist das aber definitiv nicht

eine etwas größere Webanwendung drauf laufen die unter anderem mit folgenden Technologien entwickelt werden soll (Angular, NodeJS, GO, HTML, CSS)

Ich gehe davon aus dass du keinen Einfluss auf die Struktur hast und ich kenne den Aufbau nicht, aber das klingt nach mehreren Container. Wild geraten; GINX Webserver für statische Dateien und Proxy an den NodeJS Container. Das GO-Backend ist nur vom NodeJS Container über eine NetworkPolicy und Service-Definition erreichbar.

Hat jemand von euch GitLab Runner über Kubernetes am laufen, ich habe gesehen diesen muss ich über Helm installieren und kann mir dort Tipps und tricks nennen wie ich das umsetzen kann?

Bei Kubernetes-Installationen empfiehlt es sich generell einen Service-Node ausserhalb des Clusters zu haben (auch Bastion genannt) welcher NFS, technischen HTTP-Server und SSH-Zugang auf die Nodes verwirklicht. Auf diesem Service-Node installiere ich dann auch Helm, Monitoring-API und all das andere technische Mitbringsel.


Spezifisch Gitlab Runner habe ich noch nicht installiert, Helmcharts funktionieren aber immer nach dem gleichen Prinzip. Die Dokumentation sieht auf den ersten Blick kompletter aus als so manchen Helmchart den ich installieren musste. https://docs.gitlab.com/runner/install/kubernetes.html
Funktionieren tut es immer nach dem gleichen Basisschema; das Chart "pullen", eine eigene values.yml erstellen oder aus chart/values.yml kopieren, dann "helm -n <NAMESPACE> install runner ./chart -f ./values.yml" sowie nachfolgend die entsprechenden "helm upgrade...".
Die eigentliche Deploy/ReplicationSet/PVC... solltest du nicht anfassen müssen, allenfalls die PV für die PVC erstellen falls du keine dynamische Provisionierung hast (hast du aber wegen Hetzner CSI wohl)

Ich hatte an 1-2 Loadbalancer gedacht die ich vor das Cluster setze und ebenfalls mit in das Lan Netzwerk packe, dazu hatte ich überlegt auf Haproxy zurück zu greifen?

HTTP(S)-Verkehr ist _DAS_ Steckenpferd von Kubernetes-Cluster. Die einfachste Implementierung ist die Installation eines Ingress-Controllers, also einer Reihe Container welche auf deinem Kubernetes laufen und via NodePort 80/443 erreichbar machen, . ZB: https://haproxy-ingress.github.io/
In jeder Applikation definierst du dann lediglich die Route (Ingress-Ressource) von Hostname und Pfad auf welcher der Service erreichbar ist, der Ingress-Controller kümmert sich dann um alle Details inklusive (falls gewünscht) TLS-Terminierung.

Jeder Kubernetes-Node kann im Resultat für alle Applikationen terminieren. Da aber das direkte Aufrufen eines Nodes für einen single-point-of-failure sorgen würde, ist empfehlenswert einen externen Netzwerk-Loadbalancer des Anbieters vor zu schalten um die Last auf alle Nodes zu verteilen. Kubernetes kümmert sich über sein internes Netzwerk um die Kommunikation aller Container, Services, Endpoints, Router, ...

Wozu habt Ihr euer Cluster, welche Module könnt Ihr empfehlen die man unbedingt installieren sollte

Ich arbeite hauptsächlich mit Openshift. Diese Plattform abstrahiert sehr viele Arbeitsschritte von Kubernetes weg und inkludiert die üblichen Features (Alerting, Monitoring, Ingress-Routing, ...). Es kann sein dass meine Erklärungen teilweise in Kubernetes abweichend sind. Falls interessiert kannst du aber auch OKD4 (das FOSS Upstream von Openshift) ansehen. Ein hübsches Konzept von Openshift sind Operators, also Lifecycle-Verwaltung von Controller und CRD's.

Beachte aber dass Kubernetes-Cluster in voller Strukturbreite ein ENORMER Ressourcenaufwand sind nur um sie am laufen zu haben. Rein beispielhaft auf Basis von generellen Empfehlungen der Anbieter:
- 1 Bastion-Server (2 CPU, 4GB RAM)
- 2 NFS-Server mit Aktiv-Passiv Hochverfügbarkeit (jeweils 2 CPU, 4GB RAM)
- 1 Bootstrap Node (4CPU, 16GB, ausgeschaltet nach Installation)
- 3 Master (jeweils 4CPU, 16GB RAM)
- 3 Infrastruktur (jeweils 4CPU, 16GB RAM) <-- Routing, Build-Server, Ingress, Egress, ....
- 2 Worker (jeweils 4CPU, 16GB RAM)
=================
Total: 42 CPU, 156GB RAM

 

[Milchbroetchen]

Vorweg ein Kommentar zu deiner Infrastruktur; für Produktivbetrieb sollte man keinen Single-Master fahren. Falls der Master gestört ist verlierst du das Scheduling über alle Worker-Nodes und wenn er beschädigt ist, heißt es "Restore from Backup" für ETCD mit Crash aller laufenden Container. Um StarWars zu paraphrasieren; „Immer zu dritt sie sind. Keiner mehr, keiner weniger… Ein Leader und zwei Follower."
Theoretisch kannst du beliebig viele oder wenige Master haben, für Redundanz der Komposenten und Quorum soll es aber immer ungerade sein. Kubernetes-ETCD ist darauf ausgelegt auf 3 Nodes zu laufen.

Genau das dachte ich mir bereits und habe dies an erster Stelle der "Problemliste", danke dafür nochmal.

Ich gehe davon aus dass du keinen Einfluss auf die Struktur hast und ich kenne den Aufbau nicht, aber das klingt nach mehreren Container. Wild geraten; GINX Webserver für statische Dateien und Proxy an den NodeJS Container. Das GO-Backend ist nur vom NodeJS Container über eine NetworkPolicy und Service-Definition erreichbar.

Doch, tatsächlich ja da diese Software von mir/uns entwickelt wird. Das mit den mehren Containern hatte ich auch schon auf dem Schirm unteranderem hatte ich es mir so gedacht, alles was für den betrieb des Frontends benötigt wird geht in einen Container, alles was für das Backend und den Betrieb der API benötigt wird soll aufgeteilt werden. Alles in allem soll diese software Modular aufgebaut werden unteranderem auch aufgrund der Sicherheit. Denke so sollte es eigentlich ok sein von der Planung oder hast du evtl. andere vorschläge?

Mit Proxy an NodeJS Servicen habe ich mich noch nicht mit befasst genau so wie das Thema, GO und NodeJS (mit GO meine ich die Programmiersprache, nicht dass wir beide was anderes meinen)

Bei Kubernetes-Installationen empfiehlt es sich generell einen Service-Node ausserhalb des Clusters zu haben (auch Bastion genannt) welcher NFS, technischen HTTP-Server und SSH-Zugang auf die Nodes verwirklicht. Auf diesem Service-Node installiere ich dann auch Helm, Monitoring-API und all das andere technische Mitbringsel.

Was heißt externer Services Node? Reicht ein einfacher vServer auf dem ich ganz normal Docker, kubectl, kubeadm installiere, nur mit der Ausnahme diesen nicht per "kubeadm join" in das bestehende Cluster hinzuzufügen? Wozu ist denn der NFS Dienst und welches Monitoring System kannst du da empfehlen? Ich arbeite seid längerem mit Icinga.

HTTP(S)-Verkehr ist _DAS_ Steckenpferd von Kubernetes-Cluster. Die einfachste Implementierung ist die Installation eines Ingress-Controllers, also einer Reihe Container welche auf deinem Kubernetes laufen und via NodePort 80/443 erreichbar machen, . ZB: https://haproxy-ingress.github.io/
In jeder Applikation definierst du dann lediglich die Route (Ingress-Ressource) von Hostname und Pfad auf welcher der Service erreichbar ist, der Ingress-Controller kümmert sich dann um alle Details inklusive (falls gewünscht) TLS-Terminierung.

Jeder Kubernetes-Node kann im Resultat für alle Applikationen terminieren. Da aber das direkte Aufrufen eines Nodes für einen single-point-of-failure sorgen würde, ist empfehlenswert einen externen Netzwerk-Loadbalancer des Anbieters vor zu schalten um die Last auf alle Nodes zu verteilen. Kubernetes kümmert sich über sein internes Netzwerk um die Kommunikation aller Container, Services, Endpoints, Router, ...

Ingress werde ich mir mal ansehen bzw. bin schon dabei, habe damit noch nie gearbeitet. Zur zeit habe ich halt eine einfache Testinfrastruktur in der Hetzner Cloud am laufen und hatte da gedacht, testweise die Hetzner LB's zu nutzen jeweils auch 2-3 Stk. an unterschiedlichen Orten.

Wenn alles so weit funktioniert hatte ich überlegt, erstmal eine Doku anzulegen, zwecksaufbau, Installation, Konfiguration etc. und dann auf "echte" Dedizierte Server umzusteigen und diese auch mit Ansible zu installieren, also alles automatisiert.

Ich bin jedoch für weitere Vorschläge/änderungen weiterhin sehr offen und danke euch bereits sehr dafür!

Gruß
Ich

 

[Milchbroetchen]

Beachte aber dass Kubernetes-Cluster in voller Strukturbreite ein ENORMER Ressourcenaufwand sind nur um sie am laufen zu haben. Rein beispielhaft auf Basis von generellen Empfehlungen der Anbieter:
- 1 Bastion-Server (2 CPU, 4GB RAM)
- 2 NFS-Server mit Aktiv-Passiv Hochverfügbarkeit (jeweils 2 CPU, 4GB RAM)
- 1 Bootstrap Node (4CPU, 16GB, ausgeschaltet nach Installation)
- 3 Master (jeweils 4CPU, 16GB RAM)
- 3 Infrastruktur (jeweils 4CPU, 16GB RAM) <-- Routing, Build-Server, Ingress, Egress, ....
- 2 Worker (jeweils 4CPU, 16GB RAM)
=================
Total: 42 CPU, 156GB RAM

Das ist natürlich einiges an Ressourcen, aber irgendwie habe ich mir das schon gedacht und auch mit einkalkuliert, wenn das ganze System natürlich Live geht kommen für mich und das Unternehmen eh nur die DELL Server von Hetzner in frage oder halt eigene Infrastruktur, wobei da wieder Wartung, Ersatzteile etc. mit einfließen.

 

[d4f]

oder halt eigene Infrastruktur, wobei da wieder Wartung, Ersatzteile etc. mit einfließen.

In der Basisform (ohne persistente Daten *IM* Cluster, ohne spezielle Hardwarebedürfnisse) ist Kubernetes ein Prima Beispiel genau für das Gegenteil. Deine ganze Infrastruktur kann aus jeweils den billigsten Pizzaboxen bestehen und eine groteske SLA haben, solange mindestens genug Worker überleben um die Workload zu stemmen und 2 der 3 Master laufen ist alles fit. Nichts stört Kubernetes wenn ein kleiner Desktop-Quadcore neben einem Multi-Socket XeonGold werkelt.

Grundsätzlich installiert man bei jeglichem Problem einfach den Worker neu sobald die Hardware wieder fit ist (sofern notwendig). RAID, BBU-Cache, 24/7 SLA... meh wer braucht das schon? Sofern ECC und der L3-Cache dich nicht locken, schaffen die Consumer-Hardwares von Hetzner die Arbeitslast genau so gut solange alle Netzwerk- und Systemanforderungen erfüllt sind.

Es ist halt eine Frage des Ziels. Kubernetes ist exzellent für das einfache Verwalten vieler Projekte eines Kunden (Tenant) oder multi-Tenant. Für einzelne Container-Umgebungen die einfach nur viel Leistung brauchen gibt es alternativ entweder abgespeckte Kubernetes oder schlicht simplere Alternativen (Docker Stack/Docker Swarm)

 

[Milchbroetchen]

In der Basisform (ohne persistente Daten *IM* Cluster, ohne spezielle Hardwarebedürfnisse) ist Kubernetes ein Prima Beispiel genau für das Gegenteil. Deine ganze Infrastruktur kann aus jeweils den billigsten Pizzaboxen bestehen und eine groteske SLA haben, solange mindestens genug Worker überleben um die Workload zu stemmen und 2 der 3 Master laufen ist alles fit. Nichts stört Kubernetes wenn ein kleiner Desktop-Quadcore neben einem Multi-Socket XeonGold werkelt.

Das ist in der Tat ein enormer Vorteil, was mir absolut gelegen kommt.

Grundsätzlich installiert man bei jeglichem Problem einfach den Worker neu sobald die Hardware wieder fit ist (sofern notwendig). RAID, BBU-Cache, 24/7 SLA... meh wer braucht das schon? Sofern ECC und der L3-Cache dich nicht locken, schaffen die Consumer-Hardwares von Hetzner die Arbeitslast genau so gut solange alle Netzwerk- und Systemanforderungen erfüllt sind.

24/7 Slam brauche ich dann aufgrund von Punkt 1. definitiv nicht, ECC und L3 sind dann schon Nice to have aber aufgrund von Punkt 1 quasi auch "erstmal" zweitrangig.

Es ist halt eine Frage des Ziels. Kubernetes ist exzellent für das einfache Verwalten vieler Projekte eines Kunden (Tenant) oder multi-Tenant. Für einzelne Container-Umgebungen die einfach nur viel Leistung brauchen gibt es alternativ entweder abgespeckte Kubernetes oder schlicht simplere Alternativen (Docker Stack/Docker Swarm)

Also es werden definitiv mehre Projekte kommen, auch von mehren Kunden die gerade in diesem Bereich sehr aktiv unterwegs sind und Anwendungen (Produktiv haben).

Das freut mich, dass man als Provider für K8S Cluster, dann doch nicht zwingend auf Enterprise Hardware angewiesen ist, solange halt genug von den anderen da sind, die im falle des Falles alles übernehmen können ohne Probleme.

 

[marce]

Wozu ist denn der NFS Dienst

meist kommt man irgendwann in die Verlegenheit, statische oder persistente Daten haben zu müssen - und da kommt dann meist irgendeine Form von Netzwerkstorage im Einsatz - gern genommen ist da NFS oder - je nach Anwendungsanforderung - Blockstorage in Form von S3 oder ähnlichem.

... und das halt meist als externer Node, da alles, was im K8s läuft darauf ausgelegt sein sollte, als Wegwerfsystem zu funktionieren.

(ok, es gibt auch die Option, NFS oder DBs im K8s laufen zu lassen - aber dann brauchen diese Nodes auch wiederum einen externen, persistenten Storage)

 

[Milchbroetchen]

... und das halt meist als externer Node, da alles, was im K8s läuft darauf ausgelegt sein sollte, als Wegwerfsystem zu funktionieren.

In wie fern als externer Node? Würde theoretisch ein Server reichen auf dem kein Docker, K8S, etc. Installiert ist? Das heißt einfach NFS drauf und dann den Mount auf dem K8S Cluster zu mounten?

 

[d4f]

NFS hat den Vorteil dass es alle 3 Zugriffstypen Rwx, rox und rwo beherrscht und dabei sehr simpel zu betreiben ist, weshalb es gerne als Basislösung für persistenten Speicher ohne große IOps-Ansprüche genutzt wird.
Speicher auf den Cluster-Member selber ist dann ein Wegwerfartikel (ausser etcd welchen du cron-basiert backuppen und compacten sollst).

Genau, ein kleiner Server im gleichen Netz wie deine controlplane reicht aus. Beachte dass die darauf basierenden Dienste (bspw Registry) ausfallen wenn die VM ausfällt, ggf sollte hier also Redundanz mit autofailover (zB pacemaker) vorgesehen werden oder du legst alles direkt auf hetzner.csi falls die Zugriffsmodi es erlauben.

Also es werden definitiv mehre Projekte kommen, auch von mehren Kunden die gerade in diesem Bereich sehr aktiv unterwegs sind und Anwendungen (Produktiv haben)

Wenn du Kunden den Zugriff auf den Cluster geben willst, würde ich empfehlen nicht auf ein pures Kubernetes zu setzen sondern eine gefertigte Distro wie Rancher oder Openshift/Okd. Gerade hier spielen sie ihre Stärken von erhöhter Basissicherheit und vordefinierten Konfigurationen sehr gut aus.
In aller Regel aber wichtig; pro Projekt und Environment getrennte Namespaces!

 

[Milchbroetchen]

Genau, ein kleiner Server im gleichen Netz wie deine controlplane reicht aus. Beachte dass die darauf basierenden Dienste (bspw Registry) ausfallen wenn die VM ausfällt, ggf sollte hier also Redundanz mit autofailover (zB pacemaker) vorgesehen werden oder du legst alles direkt auf hetzner.csi falls die Zugriffsmodi es erlauben.

Vielen Dank, jetzt verstehe ich glaube ich denn Sinn wozu der externe Storage Server ist. Da werden denke ich mal die ganzen configs abgelegt die der/die Masterplane Server benötigen und der etcd.? Sprich fällt einer aus funktionieren die beiden anderen weiter?

Wenn du Kunden den Zugriff auf den Cluster geben willst, würde ich empfehlen nicht auf ein pures Kubernetes zu setzen sondern eine gefertigte Distro wie Rancher oder Openshift/Okd. Gerade hier spielen sie ihre Stärken von erhöhter Basissicherheit und vordefinierten Konfigurationen sehr gut aus.
In aller Regel aber wichtig; pro Projekt und Environment getrennte Namespaces!

vielen Dank! Rancher werde ich mir mal ansehen, davon habe ich noch nicht gehört.

 

[Milchbroetchen]

Kurzes Update:
Der NFS Server läuft nun in meiner Testumgebung habe ich diesen wie folgt realisiert.

2x Cloud Server von Hetzner die jeweils eine öffentliche IP haben, ein internes Netz haben (über diesem läuft die Replikation) und eine Floating IP über diese wird der Share angesprochen. Zusätzlich dazu habe ich an beide Server jeweils ein eigenes Cloud Volume angehangen, auf diese sollen gegenseitig gespiegelt werden und als NFS Share dienen (sprich Datenablage). Die Replication funktionier bis her sehr gut und man erreicht diese auch wunderbar. Für ein Testsetup allemal zufriedenstellend. Ich denke aber, dass ich den Share nur rein aus dem LAN Interface erreichbar machen werde sprich die NFS Sachen mit in das LAN des K8S Clusters packe, einfach Sicherheitsaspekt mäßig und man soll sowas Sja auch nicht öffentlich erreichbar machen.

 

[d4f]

. Da werden denke ich mal die ganzen configs abgelegt die der/die Masterplane Server benötigen und der etcd.?

Nein, die Controlplane selber ist/soll von externen Storages unabhängig sein. ETCD ist replizierend so dass lokaler Speicher absolut ausreichend ist.
Alles was auf dem NFS lagern soll gehört zur Dataplane (Worker-Nodes), aber nicht alles was kann soll auch auf dem NFS liegen.
Klassisches Beispiel; ein EFK (Elasticsearch-Fluentd-Kibana) Stack ist sinnvoller mit 3 Instanzen mit jeweils lokalem Speicher welche über das SDN replizieren - davon abgesehen dass sowohl Speicherbelegung als auch IO-Last von ETCD, EFK und Ähnlichem schlicht unglaublich ist.

Sprich fällt einer aus funktionieren die beiden anderen weiter?

Bei der Controlplane ist das genau so gedacht. Beachte dass zur Latenzoptimierung/Störungsvermeidung übrigens die Controlplane nicht Rechenzentrum-übergreifend aufgebaut sein sollte, was Disaster-Recovery etwas komplizierter macht wenn du nicht grade eine vollredundante Infrastruktur auf Virtualisierungsebene hast.

2x Cloud Server von Hetzner die jeweils eine öffentliche IP haben, ein internes Netz haben (über diesem läuft die Replikation) und eine Floating IP über diese wird der Share angesprochen. Zusätzlich dazu habe ich an beide Server jeweils ein eigenes Cloud Volume angehangen, auf diese sollen gegenseitig gespiegelt werden und als NFS Share dienen (sprich Datenablage).

Ohne jetzt die Details der Hetzner-Methodik zu kennen, so brauchst du eigentlich nur ein einzelnes Cloud-Volumen welches von beiden VM geladen werden kann. Falls deine VM einen (virtuellen) Hardware Watchdog haben und du 2 Volumen jeweils erreichbar machen kannst, wäre Pacemaker+SBD+Corosync mit Corosync im wait_for_all und two_node Modus eine gangbare Lösung. Laut Google unterstützt Hetzner-Cloud wegen KVM Watchdogs, solltest du aber überprüfen.
SBD verhindert Split-Brain sowohl über Disk-Fencing als auch Watchdog während Pacemaker/Corosync Ethernet-Quorum bereitstellt und die Ressourcen zwischen beiden Maschinen umlegen falls eine ausfällt oder in Wartung gesetzt wird. Falls deine Distro ein RHEL/Centos-Derivat ist, gibt es die zusammenfassende "pcs" im HighAvailability Repo.

. Ich denke aber, dass ich den Share nur rein aus dem LAN Interface erreichbar machen werde sprich die NFS Sachen mit in das LAN des K8S Clusters packe, einfach Sicherheitsaspekt mäßig und man soll sowas Sja auch nicht öffentlich erreichbar mache

Ja, NFS kennt ja keine Sicherheit ausser Client-IP und Client-Portrange (keine High-Ports). Zum einen sollen Nur DNS oder IPs für den Export erlaubt werden welche auch zu deinen Nodes gehören, zum anderen solltest du sicherstellen dass die EgressIP der Container nicht auf den NFS kommt um applikatives Mounten anderer Mountpoints zu verhindern.

 

[Milchbroetchen]

Alles was auf dem NFS lagern soll gehört zur Dataplane (Worker-Nodes), aber nicht alles was kann soll auch auf dem NFS liegen.

Also quasi persistente Volumes die ich an die Container der jeweiligen Applikation anhängen kann?

Bei der Controlplane ist das genau so gedacht. Beachte dass zur Latenzoptimierung/Störungsvermeidung übrigens die Controlplane nicht Rechenzentrum-übergreifend aufgebaut sein sollte, was Disaster-Recovery etwas komplizierter macht wenn du nicht grade eine vollredundante Infrastruktur auf Virtualisierungsebene hast.

Ok, dass ist sicherlich ein Problem, die Testinfrastruktur werde ich erstmal nur virtuell betreiben, wenn alles läuft wie es soll und ich eine vernünftige Doku geschrieben habe werden diese auf dedizierte Server eingerichtet. Dann muss man natürlich schauen zwecks Disaster Recovery, Geo Redundanz etc.

Ohne jetzt die Details der Hetzner-Methodik zu kennen, so brauchst du eigentlich nur ein einzelnes Cloud-Volumen welches von beiden VM geladen werden kann. Falls deine VM einen (virtuellen) Hardware Watchdog haben und du 2 Volumen jeweils erreichbar machen kannst, wäre Pacemaker+SBD+Corosync mit Corosync im wait_for_all und two_node Modus eine gangbare Lösung. Laut Google unterstützt Hetzner-Cloud wegen KVM Watchdogs, solltest du aber überprüfen.
SBD verhindert Split-Brain sowohl über Disk-Fencing als auch Watchdog während Pacemaker/Corosync Ethernet-Quorum bereitstellt und die Ressourcen zwischen beiden Maschinen umlegen falls eine ausfällt oder in Wartung gesetzt wird. Falls deine Distro ein RHEL/Centos-Derivat ist, gibt es die zusammenfassende "pcs" im HighAvailability Repo.

Da werde ich mich definitiv auch mal einlesen und gucken wie man das jetzt beim testen gut realisieren kann und vor allem später auf den Produktivsystemen, definitiv werde ich mir für den Storage server 2x baugleiche Dedis hinstellen, diese untereinander verbinden (minimum 10G) mit jeweils SSD's als Storage drinnen, habe da an ein RAID 10 gedacht pro Server.

Ja, NFS kennt ja keine Sicherheit ausser Client-IP und Client-Portrange (keine High-Ports). Zum einen sollen Nur DNS oder IPs für den Export erlaubt werden welche auch zu deinen Nodes gehören, zum anderen solltest du sicherstellen dass die EgressIP der Container nicht auf den NFS kommt um applikatives Mounten anderer Mountpoints zu verhindern.

Vielen Dank für den Tipp mit Ingress, bei den anderen Sachen werde ich mich auch noch tiefer mit befassen um dies zu realisieren und vor allem abzusichern.

Achso, dass ganze wird übrigens ein aktuelles Debian als unterbau haben. Ich fahre seid Jahren sehr gut mit Debian und werde dies deshalb auch weiter nutzen.

 

[Milchbroetchen]

Kurzes Update: (sorry für den Doppelpost in diesem Fall)

Habe nun einen Loadbalancer aufgesetzt mittels HA Proxy, hinter diesem laufen nun 3x Control Plane Server welche über ein internes Netz kommunizieren untereinander und mit dem Haproxy. Zum aufsetzen der Control Plane HA Instanzen war die offizielle Kubernetes Doku sehr hilfreich sowie https://blog.scottlowe.org/2019/08/12/converting-kubernetes-to-ha-control-plane/

Nächste Steps sind nun die Worker Nodes hinzuzufügen, Ingress einzurichten sowie separate Namespaces.

Edit:
Dieses Howto hat mir ebenfalls sehr gut geholfen.

On-premise HA Kubernetes cluster

Overcoming infrastructural limits while setting up a production Kubernetes Cluster

itnext.io

Alle Worker verbinden sich nun über den LoadBalancer mit dem Control Plane Cluster, dies funktioniert sehr gut.

 

[d4f]

Also quasi persistente Volumes die ich an die Container der jeweiligen Applikation anhängen kann?

Genau. Einige Kubernetes-eigene (Zusatz)dienste wie die eigene Registry brauchen aber auch Speicherplatz wenn sie persistent sein sollen, so dass es nicht ganz so optional ist wie es anfangs scheint.

Ok, dass ist sicherlich ein Problem, die Testinfrastruktur werde ich erstmal nur virtuell betreiben, wenn alles läuft wie es soll und ich eine vernünftige Doku geschrieben habe werden diese auf dedizierte Server eingerichtet.

Es gibt keine technische Ursache warum die Dataplane nicht physisch und die Controlplane virtuell sein kann, beide dürfen auch gerne in getrennten Vlans liegen. VMs haben den Vorteil dass -je nach Anbieter- selbst ein zerstörtes Rechenzentrum "nur" bedeutet dass sie in einem anderen Rechenzentrum neu startet. Physische Maschinen haben dahingehend aber die notwendige Leistung um die eigentliche Arbeit zu stemmen.
Worker können problemlos im laufenden Betrieb ausgetauscht werden (startet natürlich die entsprechenden Container neu) so dass du transparent von virtuell auf physisch oder hybrid wechseln kannst. Beachte nur dass Kubernetes und seine SDN sehr gesprächig sind so dass du sicherstellen solltest dass jeder Verkehr innerhalb und zwischen Control/Dataplane kostenfrei sind.

definitiv werde ich mir für den Storage server 2x baugleiche Dedis hinstellen, diese untereinander verbinden (minimum 10G) mit jeweils SSD's als Storage drinnen, habe da an ein RAID 10 gedacht pro Server.

Nur um eine weitere Idee in den Ring zu werfen; immer populärer wird auch um Ceph auf den Kubernetes Worker zu betreiben. Auch hier ist RAID wieder nicht notwendig da erasure-coding (oder bei nur 2 Nodes: Replikation) die Redundanz sicherstellt. Vorteil und Nachteil ist dass CPU+RAM und Speicherplatz+IOPS interdependent sind und gleichzeitig skalieren. Mehr RAM _oder_ mehr Speicherplatz heisst mehr Nodes.

Habe nun einen Loadbalancer aufgesetzt mittels HA Proxy, hinter diesem laufen nun 3x Control Plane Server welche über ein internes Netz kommunizieren untereinander und mit dem Haproxy. Z

Hier verstehe ich deinen Aufbau nicht ganz - warum die Controlplane hinter einem HAProxy?
Auf der controlplane sollte nur kube-apiserver einen vorangeschalteten Loadbalancer benötigen, oder meinst du diesen?
Die Ingress-Controller für applikativen Verkehr laufen auf den Worker-Nodes
Beachte dass der Loadbalancer redundant sein muss um keinen single-point-of-failure (SPOF) dar zu stellen. Gerne wird netzwerk-Equipment oder ein Angebot des Cloud-Providers deshalb dafür verwendet aber man kann es durchaus selber implementieren.

 

[Thunderbyte]

Kleiner Hinweis noch zum NFS Server. Man macht das auch gerne, weil man auf diesem dann unabhängig von den Anwendungsservern und im Hintergrund Snapshots und Backups machen kann (Achtung bei Datenbanken). Ein Backupsystem solltest Du Dir in diesem Setup durchaus auch noch überlegen. HA, Raids, etc. sind eine Erhöhung der Verfügbarkeit aber kein Backup.

Ansonsten Respekt an @d4f für die tiefgehenden Kenntnisse und Empfehlungen. Top!

 

[Milchbroetchen]

Es gibt keine technische Ursache warum die Dataplane nicht physisch und die Controlplane virtuell sein kann, beide dürfen auch gerne in getrennten Vlans liegen. VMs haben den Vorteil dass -je nach Anbieter- selbst ein zerstörtes Rechenzentrum "nur" bedeutet dass sie in einem anderen Rechenzentrum neu startet. Physische Maschinen haben dahingehend aber die notwendige Leistung um die eigentliche Arbeit zu stemmen.
Worker können problemlos im laufenden Betrieb ausgetauscht werden (startet natürlich die entsprechenden Container neu) so dass du transparent von virtuell auf physisch oder hybrid wechseln kannst. Beachte nur dass Kubernetes und seine SDN sehr gesprächig sind so dass du sicherstellen solltest dass jeder Verkehr innerhalb und zwischen Control/Dataplane kostenfrei sind.

Stimmt, an dieses Szenario habe ich so gar nicht gedacht. Habe es ja nun so realisiert, dass alle Worker und generell Request über den Lb an die API sprich die Control Plane server geleitet werden was hervorragend funktioniert. Denke dies werde ich definitiv auch so belassen, kommunizieren tun die einzelnen Control Planes und LB innerhalb eines privaten Netzes, d.h. nur der LaodBalancer ist öffentlich erreichbar. Denke dies ist eine gute Lösung so.

Nur um eine weitere Idee in den Ring zu werfen; immer populärer wird auch um Ceph auf den Kubernetes Worker zu betreiben. Auch hier ist RAID wieder nicht notwendig da erasure-coding (oder bei nur 2 Nodes: Replikation) die Redundanz sicherstellt. Vorteil und Nachteil ist dass CPU+RAM und Speicherplatz+IOPS interdependent sind und gleichzeitig skalieren. Mehr RAM _oder_ mehr Speicherplatz heisst mehr Nodes.

Danke dafür! An CEPH hatte ich auch schon gedacht, aber wie du schon sagtest sehr Ressourcenlastig meine Idee war jetzt einfach mal GlusterFS mit NFS sowie CEPH einander zu vergleichen und werde dann wohl nach Performance entscheiden welches ich einsetzen werde. Hatte lange Zeit einen Kunden mit mehren Proxmox Kisten und einem CEPH Cluster als Backend, lt. Kunde hatte dieser teils echt Probleme gerade wenn es um das Thema Backups ging und viel IO Last aufkam. Ich weiß leider auch nicht mehr was dieser für Hardware im Hintergrund laufen hatte.

Hier verstehe ich deinen Aufbau nicht ganz - warum die Controlplane hinter einem HAProxy?
Auf der controlplane sollte nur kube-apiserver einen vorangeschalteten Loadbalancer benötigen, oder meinst du diesen?
Die Ingress-Controller für applikativen Verkehr laufen auf den Worker-Nodes
Beachte dass der Loadbalancer redundant sein muss um keinen single-point-of-failure (SPOF) dar zu stellen. Gerne wird netzwerk-Equipment oder ein Angebot des Cloud-Providers deshalb dafür verwendet aber man kann es durchaus selber implementieren.

Ich versuche dies nachher einmal Bildlich darzustellen, denke das ist aussagekräftiger dann. Im Prinzip hab ich jetzt 3x Controlplane Server am laufen, diese werden nach außen hin über den Loadbalancer angesprochen sprich der API Server der die einzelnen Aufgaben entgegen nimmt etc. (Egal ob Worker, Kubectl, etc.) Wie gesagt werde dir gleich mal ein Bild hier reinsetzen.

Ein Backupsystem solltest Du Dir in diesem Setup durchaus auch noch überlegen. HA, Raids, etc. sind eine Erhöhung der Verfügbarkeit aber kein Backup.

Vielen Dank, definitiv ein sehr wichtiger Teil über den ich mir noch nicht wirklich Gedanken gemacht habe außer das dies ggf. extern bei einem anderem provider gelagert werden soll sowie Redundant gespiegelt werden soll. Über etwaige Techniken muss ich mich noch genauestens informieren. Ebenfalls noch über das Thema monitoring, würde sich Icinga oder Bloonix für K8S eignen?

Ansonsten Respekt an @d4f für die tiefgehenden Kenntnisse und Empfehlungen. Top!

Definitv!!! Ein riesiges Dankeschön an dich und ich bin echt stolz, dass es noch solche Leute wie dich gibt die anderen gerne helfen und vor allem eine solche expertise mitbringen. Ich entschuldige mich auch schon einmal für die grauen Haare die ich dir bereite.

Edit:

Das man etcd selbstverständlich lieber als Standalone als eigenes Cluster laufen lassen sollte habe ich auf dem Schirm, jedoch reicht erst einmal die Methode des "Stacked" etcd um einfach nicht den Rahmen an Ressourcen zu sprengen.

Fotos ist aus der offiziellen Doku von Kubernetes. (https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/)

 

[d4f]

Habe es ja nun so realisiert, dass alle Worker und generell Request über den Lb an die API sprich die Control Plane server geleitet werden was hervorragend funktioniert.

Von deinem Schema her ist das absolut richtig. Deine Controlplane ist logisch von der Dataplane getrennt in dass Dataplane-Container nicht einfach so auf die Controlplane zugreifen können, sondern über den Loadbalancer fahren. Das stimmt aber nur auf logischer Ebene, auf technischer Ebene ist das SDN sehr wohl in der Lage Verkehr zwischen den Nodes zu routen und man kann Master-Nodes als Worker-Nodes missbrauchen was aber sicherheitstechnisch riskant ist.

Du brauchst daneben noch einen zweiten Loadbalancer (kann die gleiche Instanz mit getrennter Konfig sein) welcher sowohl NodePorts für die Worker als auch Ingress-Verkehr der Worker routet.

lt. Kunde hatte dieser teils echt Probleme gerade wenn es um das Thema Backups ging und viel IO Last aufkam. Ich weiß leider auch nicht mehr was dieser für Hardware im Hintergrund laufen hatte.

QoS und Priorisierung sind absolut nicht trivial unter Ceph, spätestens während Backups kannst du sehr unangenehme Überlastungen kriegen. Ich habe aktuell keine Ceph-Kubernetes Kombo im Einsatz, würde aber empfehlen bei Cluster-basierten Speicher die interne Kommunikation auf eine getrennte Netzwerkkarte aus zu lagern. Das hast du aber selber bereits auch schon angesprochen

Ein Backupsystem solltest Du Dir in diesem Setup durchaus auch noch überlegen

Ich war anfangs wortwörtlich schockiert als ich feststellte dass weder Kubernetes noch seine populärsten Distros überhaupt sinnvolle Backuptechniken mitbringen und man alles selber skripten muss oder auf nicht-unterstützte Lösungen Dritter setzen.
Velero ist "das" Backup-System für Kubernetes-Cluster, ist aber deutlich weniger trivial und simpel als man denken würde Die Laufzeiten eines Backups sind schrecklich hoch, die Verwaltung ist... gewöhnungsbedürftig... und sie sind nicht komplett für die Konfigurationen eines Projektes ausser man beinhaltet alle Namespaces.
Bei Restic-Backups - also dass Velero sich auch um die Datensicherung kümmert - werden die Laufzeiten noch länger und ich habe nie rausfinden können wieso die Backups regelmässig fehlschlagen ohne dass erkennbare Gründe vorliegen.

ABER - und das ist sehr wichtig - wenn man über Backups der Daten oder Sicherung der laufenden Konfiguration diskutiert, läuft man Gefahr aus der Kubernetes-Methodik raus zu rutschen. Container sind definitionsbedingt Stateless, es gibt also nichts zu backupen. Deployment/PV/PVC/Egress/Service/Route/... Konfigurationen müssen im Projekt verwaltet werden und nicht auf Kubernetes. Eigentlich reichen:
- regelmässige ETCD Backups
- regelmässige Backups aller PVs ausserhalb von Kubernetes (NFS ist hier klar vorteilhaft, freie Wahl der Software für filelevel Backups)

Es gibt nur einen spezifischen Fall dass man das Backup eines spezifischen Namespaces oder einer Config einspielen muss; man hat bei der Verwaltung der Software verbockt. Hier könnte man brauchen:
- Restore eines PV oder von Dateien darauf
- Restore einer Config oder eines Namespaces
Ersterer Fall ist durch die PV-Backups ausserhalb Kubernetes bereits abgedeckt, also bleiben nur Config-/Namespace-Restores. Da Kubernetes komplett über Yaml und API gesteuert wird wäre:
- im Fall von manueller Erstellung; ein neues kubectl apply der Dateien
- im Fall von Helm: je nach Schweregrad "helm uninstall" gefolgt von "helm install"
- im Fall von Delivery-Pipelines (wie hier wohl der Fall): neu pushen

TLDR zu backups: Es sollte eigentlich keinen Fall geben wo man einzelne Namespaces aus einem Cluster-Backup restoren muss, außer man hat simple Verwaltungslogiken dass alle Projektdateien auf git liegen verpasst. Persönlich bevorzuge ich aber trotzdem die gute "sicher-ist-sicher!" Kopie welche aus dem Cluster gezogen wird
Ein volles ETCD-Backup zu restoren ist kein Hexenwerk und wunderbar für erste Tests wenn dein Cluster noch nicht in Betrieb ist (Lösch zwischen Backup und Restore einen Namespace mit Container - der Statelogik von Kubernetes beim Wiederaufbau zu zu sehen ist schön)

außer das dies ggf. extern bei einem anderem provider gelagert werden soll sowie Redundant gespiegelt werden soll.

Wir reden hier über Cloud-Native Technologien, das Lagern bei externen S3-Anbieter ist dabei sehr passend.
Wenn es etwas kontrollierter sein soll und S3 gleichzeitig als eigener Datenspeicher sich anbieter, kannst du auch ein eigenes Minio betreiben und dahinter S3-Mirroring zu Amazon.
Optionen gibt es genug

Das man etcd selbstverständlich lieber als Standalone als eigenes Cluster laufen lassen sollte habe ich auf dem Schirm

Das ist eher eine Philosophie-Entscheidung. Persönlich finde ich es unsinnig da eigentlich alle Master-Komponenten dreifache Redundanz haben sollten. Der Vorteil erschliesst sich mir eher wenn Kubernetes gigantische Cluster steuert mit hunderten Worker, allerdings würde ich dann eher auf Multi-Cloud Verwaltung setzen als eine so grosse Cloud zu betreiben welche irgendwann Engpässe aufweist.

Ebenfalls noch über das Thema monitoring, würde sich Icinga oder Bloonix für K8S eignen?

Ich bin hauptsächlich von OKD/Openshift die Kombos Prometheus/Grafana und Elasticsearch-Fluentd-Kubana gewohnt. Prometheus führt sowohl Alerting als auch rudimentäres Monitoring aus, EFK ist eher für Analyse und aktive Prüfung.
Prometheus kann an externe Notificationprovider verbunden werden (zB Slack oder Pagerduty) so dass es eigentlich die meisten wichtigen Meldungen zeitgerecht durchkriegt.
Es hilft natürlich auch den Cluster von aussen zu überwachen ob alle Nodes aktiv sind und Schedulen (das stört Prometheus in den meisten Regelsets nämlich erst wenn der Cluster unzureichend Ressourcen hat!), eine generelle Empfehlung kann ich dazu aber nicht abgeben.

Ich entschuldige mich auch schon einmal für die grauen Haare die ich dir bereite.

Ich versichere dir, die grauen Haare können überwiegend entweder Kubernetes selber oder meiner besseren Hälfte zugeordnet werden
Immer gerne geschehen, Containerisierung ist ein sehr faszinierendes und zukunftsfähiges Thema.

PS: "Just because you can, does not mean you should". Auch wenn dein Kubernetes läuft, geh nicht wirr alles draufschmeissen was man irgendwie in ein DockerCompose kriegt - das wird sich rächen. Thunderbyte hat bereits Datenbanken angesprochen wegen der Möglichkeit dass ein Container irgendwann spontan neu starten kann, ein potentiell heikles Thema.

 

[Milchbroetchen]

Hey,
erstmal vielen Dank für einen weiteren ausführlichen Beitrag von dir. Muss zugeben soglangsam erschlägt mich das Thema sehr aber man sieht wirklich gute Fortschritte. Vor allem die offizielle Doku ist schon sehr sehr gut von K8S.

Wir reden hier über Cloud-Native Technologien, das Lagern bei externen S3-Anbieter ist dabei sehr passend.
Wenn es etwas kontrollierter sein soll und S3 gleichzeitig als eigener Datenspeicher sich anbieter, kannst du auch ein eigenes Minio betreiben und dahinter S3-Mirroring zu Amazon.

Sehr gute Idee! Das Problem bzw. das Thema was mir gerade bei Amazon wieder aufstößt ist das Thema Datenschutz und wie sich das gerade bei Backups verhält im Bezug auf Kunden, dass wird auf jedenfalls auch ein sehr intensives und tiefes Thema welches ich gerade im Bezug auf Datenschutz und AGB auch mit einem Anwalt mal näher durchgehen werde wenn dies soweit ist.

Du brauchst daneben noch einen zweiten Loadbalancer (kann die gleiche Instanz mit getrennter Konfig sein) welcher sowohl NodePorts für die Worker als auch Ingress-Verkehr der Worker routet.

Da bin ich gerade tatsächlich dran, wie ich dies einrichte bzw. realisiere Ingress ist auch ein sehr großes und komplexes Thema was mich auch etwas erschlägt. Ich werde zuerst einmal gucken, dass ich einen zweiten Loadbalancer ans laufen bekomme.

Immer gerne geschehen, Containerisierung ist ein sehr faszinierendes und zukunftsfähiges Thema.

Absolut! Und es macht auch richtig richtig Spaß damit, mal etwas offtopic, ich habe auf der offiziellen Seite von K8S gesehen das man sich in einigen Bereichen Zertifizieren lassen kann, macht dies sinn oder erst wenn man ein "richtiger pro" in diesem Bereich ist? Denke das solche Zertifizierungen immer sehr gerne gesehen sind oder?

Ansonsten muss ich mir deinen Beitrag nochmal Stück für Stück durchlesen gerade im Bezug auf Monitoring und Backups, bin gerade leicht erschlagen.

Nochmals vielen lieben Dank, dass du dir die Zeit nimmst.

 

[d4f]

e Ingress ist auch ein sehr großes und komplexes Thema was mich auch etwas erschlägt.

Ich würde wie bereits angesprochen wegen den ganzen Sicherheits-, Konfigurations- und Funktionsumfängen (welche ganze Verwaltungsteams bräuchte) gar nicht auf pures Kubernetes setzen sondern auf eine Distro. Bei Suse's Rancher ist der Support optional, bei Redhat Openshift heisst die freie Variante OKD statt Openshift.

Denke das solche Zertifizierungen immer sehr gerne gesehen sind oder?

Falls du Consulting anbieten willst oder den Werbesatz "zertifiziert" verwenden können willst ist es eine sehr gute Idee. Für den Arbeitsmarkt auch nicht unbedingt schlecht. Wie viele Zertifikate ist es aber im Allgemeinen aber nur das Geld was du durch die entsprechende Werbung/Stelle kriegen kannst wert. Will heissen; die Kurse bringen einem bereits eingestiegenen und interessierten Teilnehmer eigentlich keinen Mehrwert in der eigentlichen Arbeit, sie ermöglichen aber oft die Arbeit überhaupt zu haben.
Wenn es dir um den Lerninhalt gibt, so geben Udemy, Pluralsight, Coursera Leistung-für-Geld, .. von Dokumentation und Foren und Trial&Error ganz zu schweigen.

muss zugeben soglangsam erschlägt mich das Thema sehr aber man sieht wirklich gute Fortschritte.

Du darfst nicht erwarten dass Kubernetes eine Linux-Anwendung ist wie eine andere auch welche binnen 2 Tagen läuft. Allein die Container-Methodik (Theorie und Praxis) ist bereits bei "simplen" Docker-Umgebungen überwältigend und komplex, Kubernetes ist nochmal ein Brockhaus voller Möglichkeiten, Einschränkungen und Probleme obendrauf.
Am besten lernt es sich -meines Erachtens- im Realbetrieb einer Testumgebung. Und dabei haben wir bislang kaum an der Thematik Sicherheit gekratzt, EgressIP, NetworkPolicies, Namespace-Separation, Robot- und User-Roles sind genau so spassig wie Container-Scanning (die Registry Harbor bringt zB Aqua's Trivy mit) und Ressourcen-Limits/-Reservations.

Ich verspreche ich will dich nicht verzweifeln, aber du solltest auch nicht wie so mancher Cloud-Anbieter in der Zeitung stehen dass deine MongoDB (o.ä.) offen im Internet stand Du bist halt mit Kubernetes ein IT-Department; Datenspeicher, software-defined Networking, Container-Umgebung, Benutzerverwaltung, ...