pantrag_fisi Projektantrag: Kubernetes Testcluster

[SaltAndTilt]

Hallo zusammen, ich habe von meinem Fachbetreuer dieses Projektthema vorgeschlagen bekommen.

Ich habe auf der Basis erstmal einen ersten Entwurf eines Projektantrags gefertigt, bin mir aber sehr unsicher ob das Thema als FiSi-Thema taugt/ausreicht.
Durch meinen Fachbereich bin ich leider etwas eingeschränkt in der möglichen Auswahl an Projekten.
Bin daher schonmal für jedes Feedback spannend inkl. Verbesserungsvorschlägen.

______________________________________________

1.Projektthema
Planung und Aufbau einer Kubernetes-Testumgebung für den Fachbereich Monitoring

1.1.Ausgangssituation
Mehrere Fachbereiche wünschen sich, einige ihrer Systeme und Dienste in einer Kubernetes-Umgebung umzusetzen. Aktuell erfolgen sämtliche Dienste entweder in Citrix oder VMware.
Aktuell hat das Monitoring dementsprechend auch nur der Überwachung dieser Systeme zu tun, da nur Systeme im Livebetrieb gemonitored werden.


1.2.Zielsetzung
Ziel des Projektes ist es, dem Fachbereich Monitoring ein Kubernetes-Cluster zur Verfügung zu stellen, damit dieser die vorhandene Monitoringsoftware auf das Überwachen von Diensten in einer Kubernetes-Umgebung umzustellen und etwaige benötigte Änderungen durchzuführen.
Zudem muss überprüft werden, welche der vorhandenen Monitoringlösungen sich zur Überwachung von Kubernetes am besten eignet.
So soll sichergestellt werden, das bei der Einführung in anderen Bereichen das Monitoring garantiert funktioniert, so dass etwaige Ausfälle oder Störungen nicht unbemerkt bleiben.

1.3.Konsequenzen bei Nichtverwirklichung
Bei einer Nichtverwirklichung des Projektes kann der Fachbereich Monitoring sich erst mit Kubernetes-Monitoring auseinandersetzen, wenn dieses im Livebetrieb genutzt wird, was je nach Komplexität zu längeren Zeitfenstern führen kann, in denen die betroffenen Dienste nicht gemonitored werden können, was es den für die Dienste zuständigen Fachbereichen erschwert, etwaige Störungen schnell zu erkennen und zu beheben.

2.Projektumfeld
Das XXX ist ein Großunternehmen und der IT-Dienstleister des XXX und ist damit verantwortlich für den Betrieb der kompletten IT des XXX, u.a. Dienste, Server, Datenbanken etc.

Meine Projektarbeit findet im XXX in der Abteilung Monitoring statt.
Die Abteilung Monitoring stellt die Monitoring Infrastruktur (CheckMK, SCOM, ZIS) und erstellt individuelle Monitore, beteiligt sich bei komplexeren Problemen an der Lösung und stellt den anderen Fachbereichen individuelle Monitoringansichten zur Verfügung.

3.Phasen mit Zeitplanung

1.Definitionsphase (4 Stunden)

1.1 Analyse der IST-Situation (1 Stunde)
1.2 Definition des SOLL-Zustandes (1 Stunde)
1.3 Erstellung eines Pflichtenhefts (2 Stunden)

2.Planungsphase (6 Stunden)

2.1 Recherche zur Hardwareumsetzung (1 Stunde)
2.2 Wirtschaftlichkeitsbetrachtung der Hardwareoptionen (2 Stunden)
2.3 Recherche zu möglicher Software für Testläufe (1 Stunde)
2.4 Erstellung des Projektablaufplans (2 Stunden)

3.Durchführungsphase (13 Stunden)

3.1 Aufbau der Hardwareumgebung (3 Stunden)
3.2 Installation und Konfiguration des Betriebssystemes (1 Stunde)
3.3 Installation und Konfiguration von Kubernetes (2 Stunden)
3.3 Installation der verschiedenen Monitoringagents (2 Stunden)
3.4 Eingliederung in die Monitoring-Umgebung (1 Stunde)
3.5 Testlauf (4 Stunden)

4.Abschlussphase (8 Stunden)

4.1 SOLL-IST-Vergleich (1 Stunde)
4.2 Vergleich der verschiedenen Agents (2 Stunden)
4.2 Empfehlung einer Monitoringlösung für Kubernetes-Umgebungen (2 Stunden)
4.3 Guidelines zum Monitoring von Kubernetes (2 Stunden)
4.4 Projektübergabe (1 Stunde)

5.Dokumentation (4 Stunden)
5.1 Erstellen einer Projektdokumentation (4 Stunden)




 

[charmanta]

das kann was werden ... wenn Du genauer schaust wie denn die Infrastruktur für K. zur Verfügung gestellt werden soll ...

Das kann aber auch sehr sehr komplex werden

[Griller]

Mal eine fachliche Frage: Sollen nur folgende Monitoring-Lösungen zum Monitoren eines Kubernetes-Clusters evaluiert werden?

vor 2 Stunden schrieb SaltAndTilt:

Die Abteilung Monitoring stellt die Monitoring Infrastruktur (CheckMK, SCOM, ZIS)

Wenn ja, schmeiß den Inhalt der Klammer weg, damit überwacht man keine Containercluster.

Bearbeitet 3. Februar 2020 von Listener

[SaltAndTilt]

vor einer Stunde schrieb Listener:

Mal eine fachliche Frage: Sollen nur folgende Monitoring-Lösungen zum Monitoren eines Kubernetes-Clusters evaluiert werden?

Wäre tatsächlich eine Frage des Zeitaufwandes. Faktisch sind das die einzigen Produkte die wir einsetzen (können), aber ich ziehe in Betracht, bei der Evaluation den Vergleich zwischen CheckMK, Prometeus und Grafana zu ziehen, je nachdem wie es sich dann letztendlich zeitlich gestaltet.

Bei der Hardwareauswahl dachte ich an den Vergleich Raspberry Pi vs Standardinfrastruktur im Haus, um dann bei den Kosten wahrscheinlich auf den Pi Cluster zu kommen.

[Griller]

vor 4 Minuten schrieb SaltAndTilt:

Bei der Hardwareauswahl dachte ich an den Vergleich Raspberry Pi vs Standardinfrastruktur im Haus, um dann bei den Kosten wahrscheinlich auf den Pi Cluster zu kommen.

Das ist *böses Wort einsetzen* und hat im Enterprise-Umfeld nichts zu suchen.

vor 4 Minuten schrieb SaltAndTilt:

Faktisch sind das die einzigen Produkte die wir einsetzen (können), aber ich ziehe in Betracht, bei der Evaluation den Vergleich zwischen CheckMK, Prometeus und Grafana zu ziehen, je nachdem wie es sich dann letztendlich zeitlich gestaltet.

in Betracht ziehen, ist ein wenig dünn. Prometheus ist neben wenigen anderen, die einzige Möglichkeit um Kubernetes-Cluster ordentlich zu monitoren. CheckMK ist bestenfalls zu erwägen, weil man das vielleicht schon einsetzt, empfehlenswert für den Usecase halte ich es nicht.

[SaltAndTilt]

Der Ausbildungsbetrieb ist Teil des öD, faktisch wird das hier im Haus also auf CheckMK hinauslaufen, aber wenn es sinnvoll/gut ist, würde ich natürlich den Fokus auf den Vergleich CheckMK/Prometheus legen.

Das Pi's nicht best practice sind, ist mir schon klar.
Wenn es nicht das Pi Cluster wird, wäre der Arbeitsschritt leider nur durch ein "Linuxserver bei einem anderen Fachbereich beantragen" zu ersetzen, wird dass dann nicht schon problematisch mit der fachlichen Tiefe? Zumal das dann u.U. daran auch scheitern könnte, da die Wartezeit gegebenfalls einige Monate sein kann. Oder wäre das ein Punkt den die IHK bereits ankreidet?
 

[charmanta]

Das fachliche Problem wird bleiben dass check_mk eine Containerumgebung m.E gar nicht sinnvoll überwachen kann ?

Formuliere doch mal deutlicher aus, dass Du für eine bestehende Containerumgebung Überwachung etablieren willst und dann schaust Du mal nach gängigen !! Methoden.

check_mk gehört da eher nicht zu wie Listener schon deutlich erwähnte

 

[Griller]

Würde ebenfalls den Fokus auf Evaluierung/Ausarbeitung eines Blueprints legen. Einfach stupide den Cluster zusammenbauen können verschiedene Lösungen ja inzwischen auch schon out-of-the-box.

[SaltAndTilt]

CheckMK über Kubernetes, kann jetzt natürlich nicht einschätzen inwieweit das nur Marketingblabla ist, aber angeblich können sie Containermonitoring.

Aber dann quasi den Fokus auf die mögliche Umsetzung des Monitorings der Kubernetes und den Cluster "Zusammenbau" eher nebenbei, alles klar.

Auf jedenfall schonmal vielen Dank für die Hilfe.

[Griller]

vor 35 Minuten schrieb SaltAndTilt:

CheckMK über Kubernetes, kann jetzt natürlich nicht einschätzen inwieweit das nur Marketingblabla ist, aber angeblich können sie Containermonitoring.

Custom-Metriken lese ich da jetzt nicht raus. Das alleine wäre in jedem Cluster, den ich bisher aufgesetzt habe, ein KO-Kriterium, da alleine Velero-Metriken überwacht werden müsssen. etcd, kubedns/coredns auch. Ist für mich keine gute Lösung, so ganz kurz und knapp

Bearbeitet 3. Februar 2020 von Listener

[pr0gg3r]

vor 5 Stunden schrieb SaltAndTilt:

3.1 Aufbau der Hardwareumgebung (3 Stunden)
3.2 Installation und Konfiguration des Betriebssystemes (1 Stunde)
3.3 Installation und Konfiguration von Kubernetes (2 Stunden)

Ich glaube, du bist da etwas zu optimistisch. Kubernetes ist nicht in zwei Stunden installiert (wenn wir von einem richtigen Kubernetes und keinem Minikube ausgehen). Wie viele Nodes hast du denn geplant? 

vor 5 Stunden schrieb SaltAndTilt:

Ziel des Projektes ist es, dem Fachbereich Monitoring ein Kubernetes-Cluster zur Verfügung zu stellen, damit dieser die vorhandene Monitoringsoftware auf das Überwachen von Diensten in einer Kubernetes-Umgebung umzustellen und etwaige benötigte Änderungen durchzuführen.

Ich kenne check_mk nicht, aber wenns um Monitoring und Kubernetes geht, hört man öfter Log DNA, Elk Stack, Prmetheus, etc.

[SaltAndTilt]

vor 17 Stunden schrieb pr0gg3r:

Ich glaube, du bist da etwas zu optimistisch. Kubernetes ist nicht in zwei Stunden installiert (wenn wir von einem richtigen Kubernetes und keinem Minikube ausgehen). Wie viele Nodes hast du denn geplant? 

Ich kenne check_mk nicht, aber wenns um Monitoring und Kubernetes geht, hört man öfter Log DNA, Elk Stack, Prmetheus, etc.

Die ursprüngliche Planung war mit ~3 Pi's (1 Master, 2 Nodes), ich habe auch gerade nochmal die inoffizielle Bestätigung, dass ordentliche Hardware nicht möglich sein wird. Wenn so Rasberry Lösungen Punktabzug bedeuten, würde ich mir ein anderes Thema suchen.

vor 19 Stunden schrieb Listener:

Custom-Metriken lese ich da jetzt nicht raus. Das alleine wäre in jedem Cluster, den ich bisher aufgesetzt habe, ein KO-Kriterium, da alleine Velero-Metriken überwacht werden müsssen. etcd, kubedns/coredns auch. Ist für mich keine gute Lösung, so ganz kurz und knapp

Ich meine, ich kann im Ergebnis doch darauf kommen, dass unsere aktuelle Software für das Monitoring von Kubernetes nicht ausreicht und quasi einen Rat für die Zukunft abgeben oder?

[Griller]

vor 4 Minuten schrieb SaltAndTilt:

Die ursprüngliche Planung war mit ~3 Pi's (1 Master, 2 Nodes), ich habe auch gerade nochmal die inoffizielle Bestätigung, dass ordentliche Hardware nicht möglich sein wird. Wenn so Rasberry Lösungen Punktabzug bedeuten, würde ich mir ein anderes Thema suchen.

Weiß ich ehrlich gesagt nicht. Ich würde zumindest mal komisch gucken, wenn mir das vorgeschlagen würde.

vor 5 Minuten schrieb SaltAndTilt:

Ich meine, ich kann im Ergebnis doch darauf kommen, dass unsere aktuelle Software für das Monitoring von Kubernetes nicht ausreicht und quasi einen Rat für die Zukunft abgeben oder?

Entweder so oder du evaluierst direkt CheckMK, Prometheus und bspw. Sysdig oder NewRelic.