Um einen Bare-Metal-Server für eine Kubernetes-Deployment zu virtualisieren oder nicht zu virtualisieren

Question

Ich möchte Kubernetes auf einem großen physischen Server (24 Kerne) bereitstellen, und ich bin unsicher in Bezug auf eine Reihe von Dingen.

Was sind die Vor- und Nachteile des Erstellens von virtuellen Maschinen für den K8s-Cluster anders als das Ausführen auf Bare-Metal.

Ich habe folgende Überlegungen:

• Erstellen von VMs für Arbeitsbelastung Isolation ermöglicht. Neue vms für Experimente können erstellt und Entwicklern zugewiesen werden.
• Auf der anderen Seite, mit K8s läuft auf blankem Metall ein neues NAMESPACE kann für jeden Entwickler für Experimente erstellt werden und sie können ihren Code darin ausführen. Nach alledem sollte ihr Code in Andock-Containern laufen.

Sicherheit:

• Mit vms die Menge der Zugang zu künftigen Maintainer gegeben begrenzen würde, die Höhe des Schadens zu begrenzen, die getan werden könnte. Auf der anderen Seite wäre die primäre Aufgabe für zukünftige Maintainer das Hinzufügen/Löschen von Knoten und sie würden dafür Bare-Metal-Zugriff benötigen.

Authentication:

• Im Moment devs würde nur den Server berühren, wenn ihr Code läuft durch die CI-Pipeline und ihr Lauf Implementierungen bereitgestellt werden. Aber was ist mit dem Anzeigen von Protokollen? Könnten wir die gestaffelte kubectl-Authentifizierung einrichten, damit Entwickler nur auf die ihnen zugewiesenen Namespaces zugreifen können (ich denke, dies sollte mit dem k8s-Namespace-Autorisierungs-Plugin möglich sein).

Eine Anzahl von vms ist bereits auf dem Server vorhanden. Wäre das ein Problem?

Answer 1

128 Kerne und Zweifel .... Das ist eine Menge Kerne für einen einzelnen Server.

Für kubernetes jedoch ist dies nicht relevant: Kubernetes kann unterschiedlich große Server verwenden und sie maximal nutzen. Wenn Sie jedoch die Masterserverprozesse und die Knoten-/Workerprozesse auf einem einzelnen Server kombinieren, können Sie unerwünschte Ressourcenprobleme erstellen. Sie können diese mit Namespaces verwalten, wie Sie bereits erwähnt haben.

Wir verwenden die kontinuierliche Integration mit Namespaces in einer einzelnen dev/qa kubernetes-Umgebung, in der Änderungen ihren eigenen Namespace haben (also viele Namespaces) und in diesen Namespaces vollständige Umgebungen implementiert werden. Eine Reihe von Shell-Skripten wird verwendet, um dies zu verwalten. Dies funktioniert sowohl mit einem großen Server als auch mit kleineren (oder virtuellen) Boxen. Der Vorteil der Virtualisierung für dich könnte hauptsächlich darin bestehen, die große Box in kleinere aufzuteilen, damit du sie auch für andere Zwecke als nur kubernetes verwenden kannst (ja, kubernetes läuft außer MS Windows, keine Desktops, keine Kernelmodule für VPN, etc).

Answer 2

Ich würde Dev und Prod in Form von verschiedenen vms trennen. Ich hatte einmal eine Webapp innerhalb Docker, die zu viele Threads verwendet, so dass der Docker-Dämon auf dem Host abgestürzt ist. Es war glücklicherweise auf einen Gastgeber beschränkt. Sie können dies schützen, indem Sie Limits setzen, aber es ist ein Risiko: Ein Fehler in der Entwicklung könnte auch die Produktivität senken.

Answer 3

Ich denke die Antwort ist "es kommt darauf an!" Das ist nicht wirklich eine Antwort. Persönlich würde ich die Maschine mit Hilfe von VMs aufteilen und auf diese Weise bereitstellen. Sie haben eine größere Flexibilität in Bezug darauf, wie viel von den Ressourcen des Servers Sie ausschöpfen, und Sie können problemlos neue Umgebungen erstellen und dann einfach zerstören.

Auch wenn diese VMs wirklich groß sind, denke ich, dass es noch einfacher zu verwalten ist, auch wenn Sie bereits vorhandene VMs auf dem Rechner haben.

Aus diesem Grund gibt es keinen technischen Grund, warum Sie keinen einzigen Knotenserver ausführen können, aber möglicherweise Probleme mit Ausfallzeiten mit Upgrades (wenn dies ein Problem ist), sowie wenn dieser Server gepatcht oder neu gestartet werden muss , dann ist dein gesamter Cluster ausgefallen.

Ich würde Ihre Umgebung Bedürfnisse für HA und Uptime, sowie wie Sie VMs (wenn Sie diese Route gehen) bereitstellen, und entscheiden, was am besten für Sie funktioniert.