OpenShift 3.5 Architecture - VM Provisioning

Question

Ich wurde beauftragt, die VM-Bereitstellung für eine OpenShift-Produktionsumgebung zu empfehlen. Die OpenShift-Installationsdokumente zeigen nicht wirklich viele verschiedene Optionen. Ich weiß, dass wir hohe Verfügbarkeit wollen (die mehrere Master bedeutet), aber einige der Dinge, die ich durch sind verwirrt ein wenig bin:

• separaten Rechner für ETCD
• Infrastrukturknoten

Do Ich brauche separate Hosts/Knoten für etcd? (Vorteile scheinen performancebezogen zu sein, würden Sie aber gerne besser verstehen)

Benötige ich separate Hosts/Nodes für die Infrastrukturkomponenten (Registry, Router, etc.) oder können diese nur auf den Masterknoten gehostet werden?

Answer 1

AFAIK etcd kann auf demselben Host wie der Master sein, es sei denn, Sie haben wirklich einen großen Cluster und wollen Wartung von etcd separate OpenShift-Cluster.

Durch die Ausführung von Routern auf dedizierten Knoten wird eine hohe Verfügbarkeit erreicht und die Wahrscheinlichkeit verringert, dass Knoten aufgrund anderer Container-Arbeitslasten, die auf demselben Computer ausgeführt werden, Probleme mit der Integrität haben. Anwendungen innerhalb des OpenShift-Clusters können auch dann ausgeführt werden, wenn alle Master heruntergefahren sind (möglicherweise selten), aber Router-Knoten müssen ständig verfügbar sein, um den Datenverkehr zu bedienen.

Es gibt viele Referenzarchitekturen von RedHat Kasse blog.openshift.com veröffentlicht und redhat.com auch offizielle Dokumente

Answer 2

ETCD und Master können in demselben Knoten oder separat installiert werden. Hier finden Sie einige best practices for etcd. Wie Sie sehen, wird hier empfohlen, dass es separat installiert wird und dies würde ich vorschlagen, wenn Sie mehr Server "leisten" können. Wenn nicht, ist die gemeinsame Lokalisierung von Mastern und etcds symbiotisch, da Master CPU-intensiv sind, während etcd viel Festplatten-IO und Speicher verwendet.

In Bezug auf Infrastrukturbereitstellungen wie Router, Docker-Registrierung, EFK-Stack, Metriken usw. ist die empfohlene Bereitstellungskonfiguration (alles innerhalb Ihrer Möglichkeiten), dass Master nicht planbar sind und nur die API und das Controlling bereitstellen die Knoten. Dann können Sie Ihre planbaren Knoten in Infrastruktur- und Rechenknoten aufteilen.

• Infrastrukturknoten werden nur Anwendungen, die vom Cluster selbst oder von anderen Anwendungen (zB Gitlab oder Nexus)
• Arbeiter/Compute-Knoten Geschäftsanwendungen Gastgeber

verwendet Host eine Multi-Master-Installation Mit mit HA-Routern ist natürlich die beste Lösung, aber dann müssen Sie entscheiden, wie Sie diese HA bereitstellen möchten, ist es mit einem externen LoadBalancer oder mit IP-Failover?

Wie @debianmaster erwähnt, gibt es mehrere Referenzarchitekturdokumente, die Sie lesen können. Like this one here