OpenShift Deployment Szenarien

Aus welchen Komponenten besteht eine OpenShift Installation und was sind die gängigen Szenarien für die Verteilung dieser Komponenten in einer hochverfügbaren Umgebung.
OpenShift hat drei wesentliche Komponenten: ein oder mehrere Master, ein oder mehrere Etcd Instanzen und ein oder mehrere Nodes. Das „mehrere“ bezieht sich auf eine Installation in einer produktiven Umgebung wo es um eine hochverfügbare Lösung geht. Der Master ist das „Gehirn“ und übernimmt sämtliche Management Aufgaben des Clusters. Etcd ist ein verteilter key-value store, welches den Cluster Status und Konfiguration persistiert (aktuelle nodes, Secrets, Imagestreams, usw.). Die Nodes verrichten die eigentliche Arbeit. Der Master entscheidet was zu tun ist und welcher Node welchen Container bekommt.

All-in-One

Bei dieser Installation gibt es von jeder Komponente nur eine Instanz und alle Instanzen befinden sich auf einem physischen Host. Diese Art ist nur für Test und Demo Zwecke geeignet und keinesfalls für eine Produktionsumgebung. In früheren Posts haben wir uns mit zwei All-in-one Installation beschäftigt (oc tool und minishift).

Single master, Single etcd, multiple nodes

Eine All-in-One Lösung ist für Test, Demo und Entwicklungszwecke gedacht. Mit nur einem Node, welche die eigentlich Arbeit übernimmt, kommt man natürlich nicht weit. OpenShift kann 2.000 Nodes pro Cluster verwalten (Hier steht mehr über physische Cluster Limits). Mit diesem Szenario kann man schon große Workloads abarbeiten, da mehrere Nodes vorhanden sind. Es ist jedoch klar, dass im Falle eines Ausfalls des Masters oder der etcd Instanz, das ganze Cluster nicht mehr operabel ist. Zwar laufen die einzelnen Container auf den Nodes weiter, aber es ist nicht mehr möglich neue Container zu deployen oder Container umzuziehen, falls einer der Nodes überlastet ist.

Single master, multiple etcd, multiple nodes

Das eigentliche Problem in der OpenShift Installation ist etcd. Wenn hier die einzelne Instanz weg ist, ist der komplette „Status“ des Cluster verloren. Dabei ist es nicht einfach damit getan eine neue Instanz von etcd zu installieren, denn diese Instanzen sind mit einer ID versehen (wiederum eine Zusammensetzung aus Host bezogenen Daten). Ein neuer Host = neue ID = nicht wiederherstellbarer Cluster Status.

Da etcd also wichtig ist, sollten in einer HA Umgebung (High Availability) mehrere etcd Instanzen auf unterschiedlichen Nodes laufen. Als best practice gilt es eine ungerade Anzahl von etcd Instanzen zu haben. Dies hat mit dem RAFT protocol zu tun, welches etcd nutzt um Konsistenz zwischen den Instanzen zu gewährleisten. Bei 3 Instanzen, darf genau eine ausfallen und das Cluster ist noch voll funktionstüchtig. In dem Quorum genannten Verfahren bestimmt das Cluster seine „Gesundheit“ entscheiden zu können, also das Cluster am Leben zu halten. In der unteren Tabelle sehen Sie bei wie vielen Instanzen, wie viele davon ausfallen dürfen.

Quelle: https://coreos.com/etcd/docs/latest/faq.html

Multiple master, multiple etcd, multiple nodes

Ab einer bestimmten Arbeitslast (Anzahl container, Anzahl der Management Api Anfragen) kommt ein einzelner Master ins Schwitzen. Neben der hohen Last führt ein Ausfall eines einzelnen Master auch dazu, dass im Cluster keine neuen Deployments, Build oder sonstiges mehr ausgeführt werden kann. Die Container bleiben weiter am Leben, aber das Cluster ist nicht mehr Operabel. Damit das nicht passiert, kann und sollte man auch die Master in einer hochverfügbaren Auslegung installieren. Es ist völlig valide die Master Instanzen auf den gleichen physischen Hosts wie die etcd Instanzen zu installieren. Ich habe aber auch Installationen gesehen wo selbst diese beiden Komponenten physisch getrennt waren. Damit der Load zwischen den Master verteilt wird, benötigt man einen externen Loadbalancer wie nginx, haproxy, Netscaler oder was auch immer im Unternehmen schon existiert. Hier ein Beispielszenario:

In einem der nächsten Posts gehe ich explizit auf ein produktionsreifes Setup ein.