Nachdem Anna bereits von unserer tollen /mid Week berichtet hat, zeige ich dir in einem zweiten Teil unsere Ergebnisse und Erfahrungen aus den vielen Red Hat OpenShift Installationen. Konkret geht es um einen Vergleich zwischen on-premise mit VMware vSphere und AWS, GCP, Azure.
Nachdem wir uns während der /mid Week intensiv mit OpenShift 4.2 beschäftigt haben, möchten wir dir in diesem Blogpost unsere wichtigsten Erkenntnisse aufzeigen:
1. Installations-Pitfalls: In der /mid Week haben wir OpenShift 4.2 sowohl auf einem VMware vSphere Cluster wie auch bei AWS, GCP und Azure installiert. Wir berichten über die Probleme, die dabei aufgetaucht sind.
2. Networking: Je nach Cloud Plattform gibt es logischerweise Unterschiede (z.B. Load Balancer). Wir haben aber auch Unterschiede zwischen OpenShift 3.11 und 4.2 festgestellt.
3. Storage: Jeder Cloud Provider bietet diverse Typen von Storage zur Integration in OpenShift an. Wir zeigen euch, was es für Möglichkeiten gibt.
1. Installations-Pitfalls
Wenn du in diesem Blogpost nach einer Anleitung suchst, wie OpenShift 4.2 installiert wird, bist du leider falsch. Für die Installationen haben auch wir die offiziellen Anleitungen von Red Hat verwendet.
Vorneweg: Die Installation wird mit OpenShift Version 4.2 deutlich einfacher und schneller als mit 3.11. Generell – egal für welche Zielplattform – haben wir Folgendes festgestellt:
- Kleinere Umgebungen als 3 Master / 3 Node (Standardvorgabe) sollten nicht gewählt werden. Es wird sehr langsam oder die Installation schlägt teilweise sogar fehl.
- Für den OpenShift Installer wird ein install-config.yaml File erstellt. Dies sollte vor Beginn der Installation gesichert werden, da der Installer dieses anschliessend löscht.
- Weiter sollten auch alle Terraform Output Files gesichert werden, damit später der Cluster einfach gelöscht werden kann. Achtung, beim Löschen des Cluster erfolgt keine zusätzliche Bestätigung!
- Je nach Plattform haben wir unterschiedliche Grössen der Standard-VM festgestellt.
- Wenn während der Installation kein SSH-Keyfile angegeben wurde, kann anschliessend nicht auf die VM’s per SSH zugegriffen werden.
Die Installation eines Clusters dauert je nach Plattform unterschiedlich lange:
| Plattform | Installationsdauer |
| GCP | 27 min |
| AWS | 35 min |
| Azure | 47 min |
| VMware vSphere | 45 min |
VMware vSphere
Einige Bemerkungen zur VMware vSphere Installation:
- Die Dokumentation zur Installation war sehr gut und wir konnten dieser Schritt für Schritt folgen.
- Während der (ersten) Installation mussten wir feststellen, dass Reverse DNS Einträge zwingend notwendig sind. Die Installation war blockiert und wir mussten von neuem beginnen.
- Kleine Fehler in den Ignition (JSON) Files führen zu Fehler, die leider sehr schwer zu finden sind, da keine sinnvolle Fehlermeldung vorhanden ist. So hat uns z.B. ein fehlendes Komma etwa eine Stunde Zeit gekostet. Ignition Files können hier validiert werden.
- Für die Installation muss ein Load Balancer (z.B. HAproxy) erstellt werden. Siehe auch unten im Teil zu Networking.
- Infrastructur MachineSets für vSphere sind noch nicht implementiert. Daher ist die Installation auf VMware vSphere auch eine User Provisioned Infrastructure (UPI) Installation.
GCP
Damit die Installation auf GCP funktioniert, müssen die folgenden APIs aktiviert sein:
- Identity and Access Management (IAM)
- Cloud Resource Manager API
Weiter muss die Disksize Limit von 500GB auf 750 GB erhöht werden (640GB benutzt nach der Installation). Das Definieren im install-config.yaml File des OpenShift Installer funktioniert leider nicht:
- name:
platform:
gcp:
rootVolume:
iops: 4000
size: 50
type: io1
type: n1-standard-4
Azure
Einige Bemerkungen zur Installation auf Azure:
- Free Tier Subscription reicht nicht aus für eine OpenShift Installation.
- Es müssen Anpassungen an den default Azure Account Limits gemacht werden.
- Zürich befindet sich z.Z. nicht unter den supported Azure Regions.
- Die Dokumentation ist falsch bzgl. Azure account limits & Creating a service principal.
AWS
Die Installation auf AWS war am einfachsten. Das liegt wohl daran, dass bereits Openshift 4.0 darauf ausgelegt war.
2. Networking
Load Balancing
Für eine Red Hat OpenShift 4.2 Installation werden zwei Load Balancer vor dem Cluster benötigt:
- API Load Balancer: Für eine Hochverfügbarkeit der Kubernetes-API (welche auf dem Master läuft), müssen alle API Calls an diese Master Nodes verteilt werden.
Auf den drei Cloud Provider konnten wir dafür jeweils den Load Balancer Service des Providers verwenden. Dieser wird mit dem OpenShift Installer automatisch konfiguriert. Auf VMware vSphere mussten wir dafür selber einen Load Balancer konfigurieren. Wir haben dafür eine CentOS VM mit HAProxy verwendet. Für die hohe Verfügbarkeit kann z.B. keepalived verwendet werden.
- Client Access Load Balancer: Für den Zugriff auf den Applikation Workload wird ein Load Balancer benötigt, der die Ingress Controller weiterleitet.
Für den Client Access Load Balancer kann auf die Cloud Provider Integration von Kubernetes zurückgegriffen werden. Damit werden mit Hilfe eines Kubernetes Services vom Typ Load Balancer automatisch ein Load Balancer auf der entsprechenden Cloud Plattform provisioniert.
Bei der on-premise Installation mit VMware vSphere muss der Load Balancer selber implementiert werden, welcher den Netzwork Traffic auf die Ingress Controller weiterleitet. Das automatische Erstellen des Load Balancers via Kubernetes Service funktioniert hier leider nicht.
Egress Traffic & NetworkPolicy
- NetworkPolicy:Die Kubernetes v1 NetworkPolicy Features sind in OpenShift 4.2 verfügbar
- Egress IP: Identisch zu OpenShift 3.11. (Referenz)
- EngressNetworkPolicy wir auf OpenShift 4.2 nicht unterstützt
- EgressRouter wird auf OpenShift 4.2 nicht unterstützt
3. Storage
Abschliessend schauen wir uns noch die diversen Storage Integrationen für OpenShift 4.2 an. Wir teilen Storage in drei Kategorien ein: Block Storage, File Storage und Object Storage.
Block Storage
Erfreulicherweise hatten wir mit keinem Provider (onpremise wie auch Cloud) Probleme. Nach der Installation gemäss Anleitung konnten wir Block Storage von allen Cloud Providern beziehen. Alle Infos dazu sind in der entsprechenden Dokumentation von Red Hat zu finden.
File Storage
Als File Storage bezeichnen wir einen, der insbesondere shared bezogen werden kann (ReadWriteMany – RWX).
AWS
Auf AWS steht uns EWS zur Verfügung. Wir haben jedoch Folgendes festgestellt:
- Auf EFS sind alle Volumes nur Subfolder des Root Volume.
- Quotas können nicht forciert werden.
- Keine Usage Metrics
- size in einem PVC wird nicht berücksichtigt.
- Red Hat sagt zu EFS: „Elastic File System is a Technology Preview feature only.[…]“ Openshift doc on EFS
- upstream efs-provisioner: detailed doc & code
Weiter kann auch Netapp Trident verwendet werden. In unserer /mid Week haben wir dies jedoch nicht angeschaut (auch nicht auf den anderen Cloud Provider Plattformen). Dafür wird ein AWS Account mit konfiguriertem NetApp CVS (1TB / 100$ / Monat) benötigt. Infos dazu in der Netapp Trident Dokumentation.
Azure
Microsoft bietet mit Azure File die Möglichkeit, dynamisch File Storage zu beziehen. Die folgenden Features werden dabei aber nicht supported.
- Symlinks
- Hard links
- Extended attributes
- Sparse files
- Named pipes
Alle Informationen dazu sind in der Red Hat OpenShift Dokumentation zu finden. Auch auf Azure kann Netapp Trident verwendet werden.
GCP
Auf GCP stehen mehrere Möglichkeiten zur Verfügung.
Für Cloud File Store kann der nfs-client-provisioner verwendet weren. Auch hier können Quotas nicht forciert werden. Weiter gibt es einen nicht offiziell supporteten CSI Treiber, den wir aber nicht wirklich zum Laufen gebracht haben.
Weiter kann auch hier NetApp Cloud Volumes mit Trident verwendet werden. Wir haben hierzu aber keine Dokumentation gefunden. Dies sollte aber ähnlich wie bei AWS seine. Weitere Infos dazu sind hier zu finden.
Eine weitere Möglichkeit ist die Verwendung von Elastifile oder Quoabyte. Diese müssen aber alle lizenziert werden. Elastifile ist nur für einen eingeschränkten Kundenkreis verfügbar. Quoabyte sieht zur Zeit noch nicht wirklich Enterprise-like aus.
VMware vSphere
In einer on-premise VMware vSphere Umgebung muss einen File Storage Service selbst aufgebaut werden (z.B. mit Red Hat Contrainer Storage basierend auf rook.io).
Object Storage
Auch Object Storage wird von den drei Cloud Provider angeboten. Dieser wird aber in der Regeln nicht als PV in einen Pod gemounted, sondern direkt aus einer Applikation bezogen. Der Vollständigkeit halber hier eine Auflistung der Object Storage Services.
- GCP mit Google Cloud Storage
- AWS mit S3
- Azure mit Azure Object Storage
In einer on-premise VMware vSphere Umgebung muss ein Object Storage Service selbst aufgebaut werden.