Container Services
Damit Informatik-Organisationen die dynamischen Anforderungen zur Umsetzung ihres Geschäftsmodells erfüllen können, setzen viele Unternehmen moderne IT-Plattformen und Organisationskonzepte wie DevOps ein. Die folgenden Dienstleistungen unterstützen Kunden dabei, die Anwendungsentwicklung und den skalierbaren IT-Betrieb optimal auf die Geschäftsdynamik auszurichten.
Mit «Container Services» bietet die ix.Cloud ein umfangreiches Tool-Set, um Micro-Services vollautomatisiert deployen und effizient verwalten zu können. Dabei fokussieren sie sich vollumfänglich auf ihre Anwendungen und Prozesse, während Inventx für sie die Infrastruktur betreibt und stetig weiterentwickelt.
| Service Name | Service Kurzbeschreibung |
|---|---|
| IT-Grundschutz | Erläuterung Container Service IT-Grundschutz |
| Container Registry | Speichern und verwalten Sie ihre Docker-Container-Images sicher in der ix.Cloud |
| Agile Factory | Bietet eine Kunden individuell integrierbare und auf Openshift Kubernetes basierende DevOps Umgebung |
| AnyCloudK8s | Ist ein flexibler und agnostischer Container-Plattform-Service |
| Container Namespace | Erlauben es dem Entwickler, ausgewählte Typen bei der Programmierung miteinander zu gruppieren und mehrfach benötigten Code in Module auszulagern |
IT-Grundschutz
In diesem Abschnitt wird der allgemeine IT-Grundschutz für die Container-Services beschrieben. Sollte es bei einem spezifischen Service Abweichungen geben, werden diese im entsprechenden Service-Umfang explizit aufgeführt.
Upgrade und Patching
-
Herstellerabhängige Vorgaben: Patching und Upgrades erfolgen gemäss den Vorgaben der jeweiligen Hersteller. Die Intervalle richten sich danach, wann neue Versionen oder Patches veröffentlicht werden.
-
Kein Umgang mit Exclusions: Da es sich um ein PaaS-Umfeld handelt, werden keine individuellen Patches verteilt. Alle Patches und Upgrades erfolgen stets auf der Plattform-Ebene.
-
Emergency Patching: Bei der Identifikation einer kritischen Schwachstelle wird diese sofort gepatcht oder ein Upgrade durchgeführt, sobald eine entsprechende Lösung vom Hersteller bereitgestellt wird für die Plattform-Ebene.
Logging
- Systemlogs: Systemlogs werden in Splunk gespeichert.
- Aufbewahrungsfrist: Logs werden für einen Zeitraum von 3 Monaten aufbewahrt.
Container Registry
Die Container Registry ist ein zentraler Ort, an dem Container Images bereitgestellt werden können. Bei der Bereitstellung wird das Image automatisch einem Vulnerability-Scan unterzogen. Damit kann die Ausführung unsicherer Images verhindert werden.
Mit der Integration der Container Registry in bestehenden CI/CD-Strukturen können vollautomatische Pipelines eingerichtet werden.
Service Architektur
Service Umfang
| Leistungsmerkmale | |
|---|---|
| IT-Grundschutz | ◼ |
| Quota | ◼ |
| Vulnerability Scan | ◼ |
| Robot Account | ◼ |
| Allow Public Access | ◼ |
| Access to User Interface | ◼ |
| CVE allowlist | ◼ |
IT-Grundschutz
Patching/Upgrade Interval
| Wochen Tag | Uhr Zeit |
|---|---|
| Einmal pro Quartal, am zweiten Mittwoch vom Monat | 12:00-14:00 Uhr |
Hardening
- Externe Überprüfung: Der Service wird alle 2 Jahre durch eine externe Firma auf Sicherheitslücken und Konformität geprüft.
- Sicherstellung durch CI/CD: Der Service wird über einen Pipeline (Continuous Integration/Continuous Deployment) bereitgestellt, wodurch kontinuierlich ein sicheres und gehärtetes Setup gewährleistet wird.
Service Optionen
Die folgenden Optionen stehen im Service "Container Registry" zur Verfügung und können im Self-Service individuell eingestellt werden.
Quota
Die Quota definiert die maximale Speicherkapazität der Repository. Wenn diese erreicht wurde, können keine weiteren Images hochgeladen werden.
Die maximale Speicherkapazität der Repository kann jederzeit im Portal nach oben oder nach unten angepasst werden.
Vulnerability Scan
Der Vulnerability Scan ist standardmässig aktiviert und kann nicht deaktiviert werden. Sämtliche Images werden einmal täglich automatisch durch den Vulnerability Scanner geprüft. Damit wird sichergestellt, dass für jedes Image ein tagesaktueller Vulnerability Report vorhanden ist.
In der folgenden Tabelle werden die verfügbaren Vulnerability Scanner aufgelistet und beschrieben:
| Scanner | Beschreibung |
|---|---|
| Trivy | Einfaches Scan-Tool für Anwendungen, die nicht geschäftskritisch sind, oder wenn mit weniger komplexen verteilten Architekturen gearbeitet wird. |
| Aqua Enterprise | Erweitertes Scan-Tool für erhöte Sicherheit. Besonders empfehlenswert bei geschäftskritische und komplexe cloud-native Anwendungen. |
Der Vulnerability Scanner "Aqua Enterprise" generiert zusätzliche Kosten.
Robot Account
Robot Accounts werden im Allgemeinen für die Workflow-, Bereitstellungs- und Testautomatisierung verwendet.
Wird im Feld "Expiration time in days" der Wert "-1" eingetragen, hat der Token kein Ablaufdatum.
Allow Public Access
Um anonyme Benutzer auf eine Container Registry mit Lesezugriff zu berechtigen, muss "Allow Public Access" eingeschaltet werden.
Access to User Interface
Für die erweiterte Verwaltung der Container Registry wird der Zugriff auf das User Interface erlaubt. Auch kann über das UI zusätzlich Informationen wie z.B. der Vulnerability Report der einzelnen Images eingesehen werden.
CVE allowlist
Es kann pro Repo/Projekt eine Allow Liste erstellt werden, welches für alle Images in dieser Lokation gilt. Die Gültigkeitsdauer der Liste kann mit einem Datum definiert werden, oder das sie nie Ablauft. Der Defaultwert ist "Never expires".
Agile Factory
Die Agile Factory ist ein Container-Plattform Service, der aus einer vielzahl an Komponenten besteht, die untereinander zu einer effizienten und branchenoptimierte DevOps Umgebung verbunden werden. Alle Komponenten und die Verbindungen unter diesen werden durch Inventx nach best-practices bereitgestellt und betrieben, obwohl einzelne Komponenten auch durch den Kunde bereitgestellt werden können.
Mit diesem Service erstellen, verwalten und skalieren cloud-native Anwendungen effizient und simple. Inventx verwaltet alle Komponenten und bietet eine Entlastung für den Kunden. Entwickler können sich ganz auf die Geschäftslogik und die Eigenentwicklungen konzentrieren.
Die Agile Factory wird in drei standardisierten Architekturen/Ausführungen (Basic, Top und Premium) auf Basis des Virtual Machine Service angeboten. Die Ausführung Basic ist für nicht-produktive, die Ausführung Top für produktive und die Ausführung Premium für geschäftskritische Anwendungen zu empfehlen.
Die initiale Installation und Konfiguration sowie sämtliche Änderungen danach sind mit einem "Generic Request" oder einem "Service Request" zu beauftragen.
Dem Service Agile Factory liegt der ix.Cloud standard Service Level zugrunde und die Worker Nodes der jeweiligen Ausführungen Basic, Top und Premium legen den gültigen SLA fest.
Für den Wiederanlauf der Agile Factory muss zusätzlich zum standard Service Level mit einem Uplift von 2 Stunden gerechnet werden.
Service Architektur
Service Umfang
| Leistungsmerkmal | Basic | Top | Premium |
|---|---|---|---|
| IT-Grundschutz | ◼ | ◼ | ◼ |
| Initiales Setup | ◻ | ◻ | ◻ |
| Git Repository | ◻ | ◻ | ◻ |
| Container Registry | ◻ | ◻ | ◻ |
| Container Network | ◼ | ◼ | ◼ |
| Management Node (Master & ETCD) | ◼ | ◼ | ◼ |
| Worker Node | ◼ | ◼ | ◼ |
| Persistent Storage | ◼ | ◼ | ◼ |
| Load Balancer | ◼ | ◼ | ◼ |
| Web Application Firewall | ◻ | ◻ | ◻ |
| Server Proxy | ◻ | ◻ | ◻ |
| Kubernetes Cluster Management | ◼ | ◼ | ◼ |
| Communication Management | ◼ | ◼ | ◼ |
| Permission Management | ◼ | ◼ | ◼ |
| Monitoring (logs & metrics) | ◼ | ◼ | ◼ |
| Cluster Network Interface | - | - | ◼ |
IT-Grundschutz
Patching/Upgrade Interval
| Wochen Tag | Uhrzeit |
|---|---|
| Am Freitag nach dem zweiten Montag im Monat | 02:00-06:00 Uhr |
Hardening
- Die Vorgaben wurden im ATSB geprüft und abgenommen
- Diese werden durch die Automatisierung umgesetzt
- Diese wird durch GitOps sichergestellt
Marware-Schutz
Alle Container-Images werden in der Container Registry auf Sicherheitslücken und Schwachstellen gescannt.
Configuration Management
Das Asset Mgmt wird im GitOps sichergestellt
Configuration Management
Das Asset Mgmt wird im GitOps sichergestellt
Service Optionen
Nachfolgend sind die einzelnen Komponenten der Agile Factory im Detail beschrieben. Teils Komponenten sind zwingend notwendig und teils optional.
Initiales Setup
Die initiale Konfiguration der Agile Factory wird im Rahmen eines Projekts umgesetzt und verrechnet. Dabei werden in Zusammenarbeit die kundenindividuellen Konfigurationen spezifiziert und anschliessend implementiert.
Git Repository
Für die Versionierung von Code der Deployments ist in der Agile Factory zwingend ein Git Repository notwendig. Diese kann durch den Kunde oder durch Inventx bereitgestellt werden.
Wenn das Git Repository durch Inventx gestellt wird, dann erhält der Kunde im Inventx eigenen Git einen autorisierten Benutzer, mit dem Projekte erstellt, verwaltet und gelöscht werden können. Wird das Git Repository vom Kunde bereitgestellt, so wird im Initial Setup die Kommunikation zwischen den Komponent aufgebaut und sichergestellt.
Container Registry
Die Agile Factory benutzt für sämtliche Deployments im Kubernetes Cluster eine Container Registry. Diese Komponente kann durch den Kunden oder die Inventx bereitgestellt werden.
Wenn Inventx die Container Registry stellt, dann wird der Service Container Registry eingesetzt. In diesem Fall ist Inventx für einen störungsfreien Betrieb dieser wichtigen Komponente verantwortlich.
Wird die Container Registry vom Kunde bereitgestellt, so wird im Initial Setup die Kommunikation zwischen den beiden Komponenten Kubernetes Cluster und Container Registry sichergestellt. In diesem Fall ist der Kunde gleichermassen mitverantwortlich, dass die Kommunikation zwischen den Komponenten störungsfrei läuft.
Container Network
Für jede Agile Factory benötigt es noch ein Subnetz. Durch die Grösse des Netzes wird definiert, wie viele Worker Nodes dem Cluster maximal hinzugefügt werden kann.
| Produkt | Optionen |
|---|---|
| Openshift/Rancher | Die Netzwerkgrösse ist frei wählbar |
Management Node (Master & ETCD) für Openshift/Rancher
Der Management Node dient der Verwaltung des Kubernetes Clusters. Über den Management Node kann via CLI, GUI oder API der Kubernetes Cluster sowie darauf installierten Anwendungen verwaltet werden. Er dient als Steuerungsebene des Clusters und verwaltet ständig den Ist-Zustand des Cluster in den definierten Soll-Zustand. Der Management Nodes koordiniert alle Aufgaben einschließlich der Planung und Skalierung von Anwendungen.
Diese Klusterkomponente wird nach Inventx Best Practices entweder auf dedizierten Virtual Machine installiert und konfiguriert. Um eine Fehlertoleranz zu erreichen, wird je nach Serviceausprägung mehr als ein Management Node installiert.
Die initiale Konfiguration eines Management Nodes ist nicht veränderbar und wie folgt definiert:
| Leistungsmerkmal | Basic | Top | Premium |
|---|---|---|---|
| Anzahl Server | Rancher: 1, OpenShift: 3 | Rancher: 3, OpenShift: 3 | Rancher: 3, OpenShift: 3 |
| Service-Level | Rhodium | Rhodium | Rhodium |
| Hardware-Profile | Rancher: P2/8, OpenShift: P4/32 | Rancher: P2/8, OpenShift: P4/32 | Rancher: P2/8, OpenShift: P4/32 |
| Storage Klasse | High Performance | High Performance | High Performance |
| Backup Retention Time | 14 Tage | 14 Tage | 14 Tage |
Worker Node
Der Worker Node ist eine Virtual Machine, auf dem die Anwendungen ausgeführt werden und der vom Management Node gesteuert wird.
Anders als beim Management Node können die Hardware-Ressourcen beim Worker Node ausgewählt und angepasst werden. Entweder man fügt weitere Worker Nodes im Kubernetes Cluster hinzu (scale-out) oder man ändert das Hardware-Profile bei den bestehenden Worker Nodes (scale-up).
Die Ressourcen Anpassung der Worker Node kann mit einem "Service Request" beauftragt werden.
Die Initialkonfiguration und die Ausbauschritte pro Serviceausprägung für Openshift/Rancher sind in der folgenden Tabelle ersichtlich:
| Leistungsmerkmal | Basic | Top | Premium |
|---|---|---|---|
| Anzahl Server 1* | 2 (initial) bis 30 | 3 (initial) bis 30 | 3 (initial) bis 30 |
| Service Level | Silber | Gold | Rhodium |
| Hardware-Profile 2* | P4/16 (initial) P8/32 P8/64 |
P4/16 (initial) P8/32 P8/64 |
P4/16 (initial) P8/32 P8/64 |
| Storage Klasse | Standard | Standard | Standard |
| Backup Retention Time | 14 Tage | 14 Tage | 14 Tage |
1* Je mehr Worker Node der Cluster besitzt, desto mehr Spares (Worker Node) müssen mit einberechnet werden.
- bis 16 Worker Node 1 Spare
- ab 16 Worker Node 2 Spares
2* Weiter Hardware Profile können bei Inventx angefragt werden.
Persistent Storage
Für persistente Daten wird die Agile Factory im Initial Setup mit persistentem Storage (SVM) ausgestattet. Bei Bedarf kann der Kubernetes Cluster mit weiterem persistentem Storage ausgebaut werden.
Typischerweise wird der persistente Storage vom Service File Storage bezogen. Optional kann auch der Service Object Storage als persistenter Storage von extern genutzt werden.
Alle Storage Klassen sind georedundant. Folgende Storage Klassen werden zur Verfügung gestellt und können durch die applikationsspezifische Konfiguration eingesetzt werden.
Snapshots werden beim Erstellen entsprechender Kubernetes Ressourcen von der Applikation ausgelöst. Damit ist es möglich einen konsistenten Snapshot der Applikationsdaten zu erstellen.
| Leistungsmerkmal | Beschreibung | Storage Klassen | Reclaim Policy | Storage Klassen (deprecated) |
|---|---|---|---|---|
| Block (Snapshot fähig) | Erstellen von Snapshot ist möglich per kubeApid | block-std | Retain | netapp-block-std-ndr-$CUSTOMER-$ENV |
| Block Economy | Keine Snapshot Möglichkeiten | block-eco | Retain | netapp-block-eco-ndr-$CUSTOMER-$ENV |
| File (Snapshot fähig) | Erstellen von Snapshot ist möglich per kubeApi | file-std | Retain | netapp-file-std-ndr-$CUSTOMER-$ENV |
| File Economy | Keine Snapshot Möglichkeiten | file-eco | Retain | netapp-file-eco-ndr-$CUSTOMER-$ENV |
Empfehlungen zur Nutzung der Storage Klassen
Grundsätzlich sind die eco Storage Classes zu bevorzugen.
| Storage Class | Beschreibung |
|---|---|
| Block | Stroge Klasse für alle SAN Workloads die eigene Datensicherung benötigen, ausgelöst durch Scheduler |
| Block Economy | Stroge Klasse für alle SAN Workloads die keine eigene Datensicherung benötigen |
| File | Stroge Klasse für alle NAS Workloads die eigene Datensicherung benötogen, ausgelöst durch Scheduler |
| File Economy | Stroge Klasse für alle NAS Workloads die keine eigene Datensicherung benötigen. Diese Storage Class ist im Cluster als default markiert |
Weiter Storage Features
- Beim entfernen von PVCs und PV's mit der Reclaim Policy "Retain", wird das Volume im Backend erst nach 14 Tagen gelöscht. Das wieder bereitstellen des Volums muss per Generic Request bestellt werden
- Das Autoscaling der PVCs die eine File Storage Class nutzen, werden bei einem Schwellwert von 79% automatisch erweitert. Die Erweiterung ist abhängig von der Ausgansgrösse des PVC. Diese Prüfung der Nutzung, wird alle 5 Minuten durchgeführt.
Load Balancer
Um Anwendungen im Cluster resilient aufbauen zu können, ist der Einsatz eines Layer 7 Load Balancer oder einer Web Application Firewall zwingend notwendig.
Web Application Firewall
Um Anwendungen im Cluster resilient aufbauen zu können, ist der Einsatz einer Web Application Firewall oder eines Layer 7 Load Balancer zwingend notwendig.
Gegenüber einem Load Balancer bietet eine Web Application Firewall zusätzlicher Schütz vor unerwünschten Anfragen auf Anwendungen.
Server Proxy
Damit Anwendungen ins Internet (ausgehender Verkehr) kommunizieren können, ist die Verwendung vom Inventx Server-Proxy zwingend. Siehe dazu unseren Service Server Proxy.
Im Initial Setup wird definiert ob ein private- oder shared Server Proxy genutzt wird im Cluster.
Kubernetes Cluster Management
Die Kubernetes Cluster werden zentral mit einer der Cluster-Management Systeme Openshift/Rancher oder AnyCloudK8s verwaltet. Im Initial Setup wird mit dem Kunde definiert, welches Produkt eingesetzt wird.
Das Kubernetes Cluster Management beinhaltet im wesentlichem das monatliche Patchen sowie das Updaten/Upgraden nach Bedarf der gesamten Plattform.
Communication Management
Inventx stellt sicher, dass Anwendungen innerhalb des Clusters standardmässig nicht miteinander kommunizieren können. Auf Wunsch kann der Kunde die Kommunikation unterhalb der Anwendungen mit einer SSL-Verschlüsselung zulassen. Die SSL-Verschlüsselung wird durch ein self-signed Zertifikat sichergestellt.
Permission Management
Über die Authentication Authorization Infrastructure (AAI) und dem LDAP Operator kann ein individuelles RBAC-Konzept umgesetzt werden. Dazu werden vom Kunde definierten AD-Gruppen und Kubernetes Cluster Rollen miteinander verlinkt.
Damit Inventx beim Initial Setup alle Einrichtungen vornehmen kann, muss der Kunde folgende Informationen zur Verfügung stellen:
- gewünschte AD-Gruppen
- ein AD Read Only Benutzer
- Schlüsselmaterial für LDAPS
Monitoring (logs & metrics)
Während der Betriebszeit wird der Container Service von Inventx fortlaufend maschinell überwacht. Allfällige Events werden protokolliert, an die entsprechende Supportorganisation weitergeleitet und während der Servicezeiten bearbeitet.
Für alle Komponenten der Agile Factory welche Inventx verantwortet, werden Logs zentral gesammelt, ausgewertet und beim Erkennen von Problemen entsprechende Massnahmen durch Inventx ergriffen.
Die Logs werden während 90 Tag aufbewahrt.
AnyCloudK8s
AnyCloudK8s ist ein vielseitiger, agnostischer Container-Plattform-Service, der aus einer Vielzahl von Komponenten besteht. Diese Komponenten werden optimal miteinander verbunden, um eine effiziente und branchenspezifische DevOps-Umgebung bereitzustellen. Inventx stellt dabei alle Komponenten und deren Verbindungen gemäss Best Practices bereit und betreibt diese. Es besteht jedoch auch die Möglichkeit, dass Kunden einzelne Komponenten selbst bereitstellen.
Mit AnyCloudK8s können Unternehmen cloud-native Anwendungen effizient erstellen, verwalten und skalieren – einfach und unkompliziert. Die Plattform bietet maximale Flexibilität, unabhängig davon, welchen Cloud-Anbieter Sie verwenden.
Dank der umfassenden Verwaltung aller Komponenten durch Inventx werden Kunden massgeblich entlastet. Entwickler können sich vollständig auf die Geschäftslogik und Eigenentwicklungen konzentrieren, ohne sich mit der Infrastruktur befassen zu müssen.
Zusätzlich steht AnyCloudK8s im ix.Portal als Selfservice zur Verfuegung – inklusive einfacher Bereitstellung und Verwaltung der Umgebung direkt übers Portal.
Die Bestellung kann etwas Zeit in Anspruch nehmen, da die Netzwerkbereitstellung noch nicht vollständig End-to-End automatisiert ist. Sobald das Netzwerk verfügbar ist, wird der Cluster automatisch bereitgestellt.
Dem Service AnyCloudK8s liegt der ix.Cloud standard Service Level zugrunde und die Worker Nodes der jeweiligen Ausführungen Silber und Rhodium legen den gültigen SLA fest.
Für den Wiederanlauf des AnyCloudK8s muss zusätzlich zum standard Service Level mit einem Uplift von 1 Stunden gerechnet werden.
Service Architektur
Service Umfang
| Leistungsmerkmal | Basic | Premium |
|---|---|---|
| IT Grundschutz | ◼ | ◼ |
| Initiales Setup | ◼ | ◼ |
| Git Repository | ◻ | ◻ |
| Container Registry | ◻ | ◻ |
| Container Network | ◼ | ◼ |
| Cluster Control Plane | ◼ | ◼ |
| Worker Pool | ◼ | ◼ |
| Worker Node | ◼ | ◼ |
| Persistent Storage | ◼ | ◼ |
| Load Balancer | ◼ | ◼ |
| Web Application Firewall | ◻ | ◻ |
| Server Proxy | ◼ | ◼ |
| Kubernetes Cluster Management | ◼ | ◼ |
| Communication Management | ◼ | ◼ |
| Permission Management | ◼ | ◼ |
| Monitoring (logs & metrics) | ◼ | ◼ |
| Cluster Network Interface | ◼ | ◼ |
IT-Grundschutz
Patching/Upgrade Interval
| Wochen Tag | Uhrzeit |
|---|---|
| Am Freitag nach dem zweiten Montag im Monat | 02:00-06:00 Uhr |
Hardening
- Die Vorgaben wurden im ATSB geprüft und abgenommen
- Diese werden durch die Automatisierung mit Gitops umgesetzt
Marware-Schutz
Alle Container-Images werden in der Container Registry auf Sicherheitslücken und Schwachstellen gescannt.
Configuration Management
Das Asset Mgmt wird im GitOps und CR's (ix.Cloud Operatoren) sichergestellt
Service Optionen
Nachfolgend sind die einzelnen Komponenten der AnyCloudK8s im Detail beschrieben. Teils Komponenten sind zwingend notwendig und teils optional. Dies ist in der oberen Tabelle AnyCloudK8s Service Umfang ersichtlich.
Initiales Setup
Bei der Bestellung eines neuen Clusters kann die Bereitstellung bis zu 5 Tage dauern. Der Service ist aktuell noch nicht vollständig automatisiert, da das Netzwerk als Managed Service beim zuständigen Team separat beauftragt wird. Sobald das Netzwerk bereitsteht, wird der Cluster anschliessend vollautomatisiert bereitgestellt.
Nach der initialen Bereitstellung sind alle weiteren Service-Funktionen vollautomatisiert verfügbar, z.B. Patchen/Updates sowie das Management der Worker Pools (Erweitern, Modifizieren, Verkleinern).
Git Repository
Für die Versionierung von Code der Deployments ist in der AnyCloudK8s zwingend ein Git Repository notwendig. Diese kann durch den Kunde oder durch Inventx bereitgestellt werden.
Wenn das Git Repository durch Inventx gestellt wird, dann erhält der Kunde im Inventx eigenen Git einen autorisierten Benutzer, mit dem Projekte erstellt, verwaltet und gelöscht werden können. Wird das Git Repository vom Kunde bereitgestellt, so wird im Initial Setup die Kommunikation zwischen den Komponent aufgebaut und sichergestellt.
Container Registry
Die AnyCloudK8s benutzt für sämtliche Deployments im Kubernetes Cluster eine Container Registry. Diese Komponente kann durch den Kunden oder die Inventx bereitgestellt werden.
Wenn Inventx die Container Registry stellt, dann wird der Service Container Registry eingesetzt. In diesem Fall ist Inventx für einen störungsfreien Betrieb dieser wichtigen Komponente verantwortlich.
Wird die Container Registry vom Kunde bereitgestellt, so wird im Initial Setup die Kommunikation zwischen den beiden Komponenten Kubernetes Cluster und Container Registry sichergestellt. In diesem Fall ist der Kunde gleichermassen mitverantwortlich, dass die Kommunikation zwischen den Komponenten störungsfrei läuft.
Container Network
Für die AnyCloudK8s Umgebung benötigt es noch ein Subnetz. Durch die Grösse des Netzes wird definiert, wie viele Worker Nodes dem Cluster maximal hinzugefügt werden kann.
Bitte beachten, dass der gesamte IP-Range nicht für die Worker Nodes verfügbar ist. In diesem Netzwerk werden zusätzliche Management- und PaaS-Komponenten bereitgestellt, die für die Service-Erbringung essentiell sind. Diese Komponenten benötigen eigene IP-Ressourcen, wodurch der nutzbare Bereich für die Worker Nodes entsprechend eingeschränkt wird.
Die Netzwerkgrösse sind in drei T-shirt size vordefiniert small(/27), middle(/26) und large(/25)
| T-shirt size | Maximale Worker Node |
|---|---|
| Small | 10 |
| Medium | 26 |
| Large | 58 |
Zusätzlich wir eine DHCP-VM deployt, welche die Verwaltung der IP-Adressen im Container-Netzwerk übernimmt. Dieser Service wird automatisch bei der Bereitstellung des Netzwerks für AnyCloudK8s bereitgestellt und vollständig konfiguriert. Dadurch wird sichergestellt, dass alle Komponenten nahtlos miteinander kommunizieren können und die Netzwerkressourcen effizient verwaltet werden
Die valid-lifetime = lease time ist fix auf 3600 Sekunden eingestellt.
Cluster Control Plane
Die Control Plane dient der Verwaltung des Kubernetes Clusters. Über sie kann via der Kubernetes API auf den Cluster sowie darauf installierten Anwendungen verwaltet werden. Sie dient als Steuerungsebene des Clusters und verwaltet ständig den Ist-Zustand des Cluster in den definierten Soll-Zustand. Die Control Plane koordiniert alle Aufgaben einschliesslich der Planung und Skalierung von Anwendungen.
Um eine hohe Fehlertoleranz und Ausfallsicherheit zu gewährleisten, wird die Control Plane auf einem Seed Kubernetes Cluster bereitgestell.
Die benötigten Ressourcen werden dynamisch auf IaaS-Ebene sichergestellt.
| Leistungsmerkmal | Basic | Premium |
|---|---|---|
| Seed Cluster | Lokal-Redundanz | Geo-Redundanz |
| Service-Level | Silber | Rhodium |
| Storage-Klasse | High Performance | Standard |
| Backup Retention Time | 14 Tage | 14 Tage |
Woker Pool
Ein Cluster kann aus einem oder mehreren Worker Pools bestehen. Pro Worker Pool definieren Sie einen einheitlichen Worker Node (z.B. CPU/RAM-Profil) und können so unterschiedliche Anforderungen innerhalb desselben Clusters gezielt abdecken.
Wann mehrere Worker Pools sinnvoll sind
Man nutzt mehrere Worker Pools, um unterschiedliche Worker Node – etwa allgemeine Knoten und solche mit viel Arbeitsspeicher – in einem Cluster zu kombinieren und Workloads entsprechend zu verteilen. Mithilfe von Taints und Tolerations sorgt man dafür, dass bestimmte Workloads nur auf dafür vorgesehenen Knoten laufen.
Gezielte Platzierung per Pod-Spezifikation: Steuern Sie die Planung über nodeSelector (oder bei Bedarf Node Affinity), damit Pods auf die passenden Worker Pools bzw. Worker Node eingeplant werden.
Worker Pools erweitert managen
Worker Pools können im Portal nicht nur erstellt und erweitert, sondern auch gezielt angepasst werden. So lassen sich unterschiedliche Worker Node, Hardware-Profile und Scheduling-Anforderungen innerhalb eines Clusters sauber trennen und über den gesamten Lebenszyklus steuern.
Erweiterte Verwaltung für Worker-Pool-Anpassungen
Mit den erweiterten Funktionen können Sie Worker Pools an derzeitige Anforderungen anpassen, ohne das gesamte Cluster neu aufzusetzen:
-
Worker Pools erweitert modifizieren Ändern Sie pool-spezifische Einstellungen wie Worker Node/Flavor, Ressourcenprofil, Metadaten sowie Scheduling-Parameter. So richten Sie Workloads auch nachträglich auf passende Node-Profile aus.
-
Worker Pools verkleinern (Scale-down) Reduzieren Sie die Anzahl Worker Nodes eines Pools kontrolliert. Dabei werden Nodes geordnet aus dem Pool entfernt, um Kapazität zu senken und Kosten zu optimieren (z.B. nach Lastspitzen oder nach Projektabschluss).
-
Taints / Labels / Annotations pro Worker Pool definieren Hinterlegen Sie Regeln und Metadaten direkt am Worker Pool:
- Labels für gezieltes Scheduling (z.B. nodeSelector / Affinity)
- Taints um Pools für spezielle Workloads zu reservieren (z.B. GPU, High-Memory) und nur per Tolerations zuzulassen
- Annotations für zusätzliche Steuerungs- und Integrationsinfos (z.B. Betrieb, Monitoring, Automatisierung)
Worker Node
Der Worker Node ist eine Virtual Machine, auf dem die Anwendungen ausgeführt werden und der vom Management Node gesteuert wird.
Anders als beim Management Node können die Hardware-Ressourcen beim Worker Node ausgewählt und angepasst werden. Entweder man fügt weitere Worker Nodes im Kubernetes Cluster hinzu (scale-out) oder man ändert das Hardware-Profile bei den bestehenden Worker Nodes (scale-up).
Ein Ausbau kann durch den Worker Pool selbständig getätigt werden.
| Standard | RAM in GB | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 4 | 8 | 16 | 24 | 32 | 64 | 96 | 128 | 256 | ||
Anzahl vCPU |
2 | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ |
| 4 | ⁃ | ◼ | ◼ | ⁃ | ◼ | ◼ | ⁃ | ⁃ | ⁃ | |
| 6 | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | |
| 8 | ⁃ | ⁃ | ◼ | ⁃ | ◼ | ◼ | ⁃ | ◼ | ⁃ | |
| 12 | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | |
| 16 | ⁃ | ⁃ | ⁃ | ⁃ | ◼ | ◼ | ⁃ | ◼ | ◼ | |
| 24 | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | |
| Systemdisk | FlatCar: 80 GB | |||||||||
Der Unterschied zu AgileFactory wird bei AnyCloudK8s zuerst eem Cluster ein Worker Node beigefügt, somit müssen keine zusätzliche Spare Nodes bereitgestellt werde. Der Ausbau ist im Backend automatisiert und kann schneller bereitgestellt werden.
1* Weiter Hardware Profile können bei Inventx angefragt werden.
Persistent Storage
Für persistente Daten wird die AnyCloudK8s im Initial Setup mit persistem Storage (SVM) ausgestatet. Es kann pro Cluster nur ein persister Storage im Subnetz bereitgestellt werden.
Typischerweise wird der persistente Storage vom Service File Storage bezogen. Optional kann auch der Service Object Storage als persistenter Storage von extern genutzt werden.
Bei AnyCloudK8s werden die Storage Klassen gemäss SLA des Cluster automatisch bereitgestellt
| Leistungsmerkmal | Basic | Premium |
|---|---|---|
| Cluster | Lokal-Redundanz | Geo-Redundanz |
| Persistem Storage | Lokal-Redundanz | Geo-Redundanz |
Folgende Storage Klassen werden zur Verfügung gestellt und können durch die applikationsspezifische Konfiguration eingesetzt werden.
| Leistungsmerkmal | Beschreibung | Storage Klassen | Reclaim Policy |
|---|---|---|---|
| Block (Snapshot fähig) | Erstellen von Snapshot ist möglich per kubeApid | block-std | Retain |
| Block Economy | Keine Snapshot Möglichkeiten | block-eco | Retain |
| File (Snapshot fähig) | Erstellen von Snapshot ist möglich per kubeApi | file-std | Retain |
| File Economy | Keine Snapshot Möglichkeiten | file-eco | Retain |
Snapshots werden beim Erstellen entsprechender Kubernetes Ressourcen von der Applikation ausgelöst. Damit ist es möglich einen konsistenten Snapshot der Applikationsdaten zu erstellen.
Empfehlungen zur Nutzung der Storage Klassen
Grundsätzlich sind die eco Storage Classes zu bevorzugen.
| Storage Class | Beschreibung |
|---|---|
| Block | Stroge Klasse für alle SAN Workloads die eigene Datensicherung benötigen, ausgelöst durch Scheduler |
| Block Economy | Stroge Klasse für alle SAN Workloads die keine eigene Datensicherung benötigen |
| File | Stroge Klasse für alle NAS Workloads die eigene Datensicherung benötogen, ausgelöst durch Scheduler |
| File Economy (default) | Stroge Klasse für alle NAS Workloads die keine eigene Datensicherung benötigen. Diese Storage Class ist im Cluster als default markiert |
Weitere Storage Features
- Beim entfernen von PVCs und PV's mit der Reclaim Policy "Retain", wird das Volume im Backend erst nach 14 Tagen gelöscht. Das wieder bereitstellen des Volums muss per Generic Request bestellt werden
- Das Autoscaling der PVCs die eine File Storage Class nutzen, werden bei einem Schwellwert von 79% automatisch erweitert. Die Erweiterung ist abhängig von der Ausgansgrösse des PVC. Diese Prüfung der Nutzung, wird alle 5 Minuten durchgeführt.
Load Balancer
Um Anwendungen im Cluster resilient aufbauen zu können, ist der Einsatz eines Layer 4/7 Load Balancer oder einer Web Application Firewall zwingend notwendig.
Bei der Bereitstellung eines AnyCloudK8s-Clusters wird kein Load Balancer automatisch installiert oder konfiguriert. Wenn ein Load Balancer benötigt wird, definiert der Kunde diesen selbst im Cluster per Manifest (z.B. als Service vom Typ LoadBalancer, gemäss bereitgestellter Vorlage).
apiVersion: v1
kind: Service
metadata:
name: loadbalancer-sample
annotations:
lb.ixcloud.ch/enable: ""
lb.ixcloud.ch/retain: ""
lb.ixcloud.ch/fqdn: "only-test.[FQDN]"
lb.ixcloud.ch/loadBalancingAlgorithm: "LeastConnections"
lb.ixcloud.ch/maxThroughput: "10"
lb.ixcloud.ch/costCenter: "[Cost124]"
spec:
type: LoadBalancer
selector:
app: my-app # muss zu den Pod-Labels passen
ports:
- name: http
port: 80
targetPort: 8080
protocol: TCP
Sobald der Load Balancer im Cluster definiert ist, sorgt unsere Automatisierung dafür, dass die Backend-Konfiguration bei Änderungen (z.B. bei einer Anpassung der IP-Adresse oder Patchen/Upgrade) automatisch aktualisiert wird.
Merkmale
- Automatisierte Anpassungen: Änderungen an Backend-Konfigurationen erfolgen ohne manuellen Eingriff.
- Skalierbarkeit: Pro Cluster können mehrere Load Balancer gleichzeitig verwaltet werden, um komplexere Anforderungen zu unterstützen.
Diese Automatisierung sorgt für eine effiziente und fehlerfreie Verwaltung der Netzwerkkomponenten und erleichtert die Skalierung und Erweiterung der Cluster-Infrastruktur.
Web Application Firewall
Um Anwendungen im Cluster resilient aufbauen zu können, ist der Einsatz einer Web Application Firewall oder eines Layer 7 Load Balancer zwingend notwendig.
- Gegenüber einem Load Balancer bietet eine Web Application Firewall zusätzlicher Schütz vor unerwünschten Anfragen auf Anwendungen.
- Wenn ein L7-Load-Balancer oder eine WAF benötigt wird, stellen Sie bitte zuerst einen L4-Load-Balancer per Manifest im Cluster bereit. Anschliessend kann dieser über einen Generic Request entsprechend zu L7 bzw. WAF umfunktioniert werden.
Server Proxy
Damit Anwendungen innerhalb des AnyCloudK8s-Clusters mit dem Internet kommunizieren können (ausgehender Verkehr), ist die Nutzung des Inventx Server-Proxys zwingend erforderlich. Weitere Details hierzu finden Sie in der Dokumentation unseres Service Server Proxy.
Bei der Bereitstellung eines AnyCloudK8s Cluster wird immer nur der shared Server Proxy genutzt. Diese stellt sicher, dass alle ausgehenden Verbindungen den Sicherheits- und Compliance-Anforderungen von Inventx entsprechen.
Kubernetes Cluster Management
Die Kubernetes-Cluster von AnyCloudK8s werden zentral durch Inventx verwaltet. Ein zentrales Merkmal dieses Ansatzes ist die Entkopplung der Control Plane aus dem Cluster. Dadurch erhält der Besteller Admin-Rechte auf dem Cluster, während Inventx die übergreifende Verwaltung sicherstellt.
Inventx stellt regelmässig unterstützte und aktuelle Patches sowie neue Kubernetes-Versionen zur Verfügung, die vom Kunden bei Bedarf für Upgrades genutzt werden können. Ankündigungen zu neuen Versionen sowie Abkündigungen von bestehenden Versionen erfolgen monatlich über Release-Notes gemäß dem ixCloud-Prozess.
Dieses Management-Modell gewährleistet die Sicherheit, Stabilität und Aktualität der Kubernetes-Umgebung, während der Kunde maximale Flexibilität für die Verwaltung seines Clusters behält.
Communication Management
Inventx stellt sicher, dass Anwendungen innerhalb des Clusters standardmässig nicht miteinander kommunizieren können. Auf Wunsch kann der Kunde die Kommunikation unterhalb der Anwendungen mit einer SSL-Verschlüsselung zulassen. Die SSL-Verschlüsselung wird durch ein self-signed Zertifikat sichergestellt.
Permission Management
Wie im Kubernetes Cluster Management beschrieben, erhält der Besteller Admin-Berechtigungen für den bereitgestellten Cluster. Diese Berechtigungen ermöglichen dem Kunden volle Kontrolle und Flexibilität bei der Verwaltung und Nutzung des Clusters.
Über das Portal kann die entsprechende Kubeconfig unkompliziert heruntergeladen werden. Mit dieser Konfigurationsdatei können Admins direkt über ihre bevorzugten Tools (z. B. kubectl) auf den Cluster zugreifen.
Monitoring (logs & metrics)
Während der Betriebszeit wird der Container Service von Inventx fortlaufend maschinell überwacht. Allfällige Events werden protokolliert, an die entsprechende Supportorganisation weitergeleitet und während der Servicezeiten bearbeitet.
Für alle Komponenten der AnyCloudK8s welche Inventx verantwortet, werden Logs zentral gesammelt, ausgewertet und beim Erkennen von Problemen entsprechende Massnahmen durch Inventx ergriffen.
Die Logs werden während 90 Tag aufbewahrt
Bei der Bereitstellung eines Clusters wird im Portal automatisch eine Time Series Database unter der gleichen Subscription eingerichtet. Die Metriken des Clusters werden in diese Datasource übertragen.
Die Datasource dient zur Speicherung und Analyse der Metriken, was eine kontinuierliche Überwachung und Optimierung des Clusters ermöglicht.
Diese Integration stellt sicher, dass alle relevanten Metriken zentral gesammelt und bei Bedarf für Monitoring- oder Reporting-Zwecke genutzt werden können.
Cluster Network Interface
Die Cluster können standardmässig mit dem Container Network Interface (CNI) Canal oder Cilium bereitgestellt werden.
Canal kombiniert die Funktionalitäten von Flannel (für das Netzwerk-Overlay) und Calico (für Netzwerk-Sicherheitsrichtlinien), um ein robustes und flexibles Netzwerk-Setup für Kubernetes-Cluster bereitzustellen.
Cilium basiert auf eBPF und ermöglicht eine performante, skalierbare und sicherheitsorientierte Netzwerkimplementierung. Neben der Pod-zu-Pod-Konnektivität unterstützt Cilium granulare Network Policies sowie erweiterte Observability-Funktionen.
Container Namespace
Der Container Namespace Service vereinfacht die Nutzung der Agile Factory und AnyCloudK8s. Alle benötigten Clusterbase Berechtigungen für Namespace werden in diesem Service bereitgestellt.
Namespaces ist in Kubernetes zentral und ein Key-Element. Namespace ermöglichen es dem Entwickler, sein Projekt modular aufzubauen und bestimmte Aspekte in eine eigene Datei auszulagern. So können sie ihre Applikationen modernisieren und die Komplexität verringern, wodurch der Entwickler sich auf das wesentliche fokussieren kann.
Service Architektur
Service Umfang
| Leistungsmerkmal | Rancher | OpenShift | AnyCloudK8s |
|---|---|---|---|
| Initiales Setup | ◻ | ◻ | ◻ |
| Target Destination | ◼ | ◼ | ◼ |
| Network Policy | ◼ | ◼ | ◼ |
| Quotas | ◼ | ◼ | ◼ |
| KubeConfig | ◼ | ◼ | ◼ |
| Annotations/Labels | ◼ | ◼ | ◼ |
Um sicherzustellen, dass systemkritische Namespaces geschützt bleiben, haben wir einen Blacklist-Filter eingeführt. Dieser stellt sicher, dass bestimmte vom Cluster genutzte Namespaces nicht bestellt werden können. Die folgenden Namespaces sind davon betroffen:
openshift openshift- ; kube- ; trident ; argocd ; cert-manager ; patch-operator ; patch-automation ; conjur ; k8s-operators ; ix-ocpbackup-system ; ix-aai ; alertmanager-zabbix-webhook ; collectorforopenshift ; cerberus ; kyverno ; aqua
Service Optionen
Nachfolgend sind die einzelnen Komponenten des Container Namespace im Detail beschrieben.
Inital Setup
Die Basis für den Einsatz eines Container Names Space bildet eine bestehende Agile Factory oder AnyCloudK8s. Die Subscription welche bei der Bestellung genutzt wird, muss vorab aufgeschaltet werden auf dem Target Destination.
Für die Freigabe der verfügbaren Target Destinationen sowie sämtliche spätere Änderungen sind mit einem "Generic Request" zu beauftragen
Target Destination
Es kann pro Subscription definiert werden, welche Target Destinationen verwendet werden können. So kann spezifisch definiert werden welche User auf welcher Agile Factory oder AnyCloudK8s einen Container Namespace respektiv eine Applikation deployen darf.
Network Policy
Beim Erstellen eines Namespace auf der Target Destination, werden vordefinierte Network Policy gesetzt. Diese müssen bei einem Deploying der Applikation gemäss Anforderungen der Applikation angepasst werden.
Auflistung der von Inventx gesetzten Netzwerk Policy's
- Allow Namespace
- Allow DNS
- Default denyAll
Quotas
Beim Erstellen eines Namespaces müssen die Quotas definiert werden. Dadurch wird die Voraussetzung geschaffen, dass Applikationen resilient auf dem entsprechenden Cluster betrieben werden können. Mittels Quotas wird sichergestellt, dass eine Applikation nicht alle Cluster-Ressourcen ausschöpfen und andere Applikationen negativ beinträchtigen kann.
Folgende Quotas müssen bei er Erstellung angegeben werden:
| Leistungsmerkmal | Beschreibung |
|---|---|
| Memory | Memory Quota in MB auf dem Namespace |
| CPU | CPU Quota in Millicpu auf dem Namespace |
| Storage | Storage in GB auf dem Namespace |
| PVC | Maximale Anzahl PVC's im Namespace |
Diese Quotas haben alle einen minimal Wert definiert, die Definitionen sind in der untern Tabelle ersichtlich:
Es gibt Applikationen welche mit den ResourceQuotas oder Networkpolicy vom Namespace nicht umgehen können. Diese können beim bestellen des Namespace deaktivieren werden
| Quota | Mindestwert |
|---|---|
| Memory | > 256MB |
| CPU | > 200m |
| Storage | >= 1 |
| PVC | >0 |
Der maximale Wert ist nicht limitiert, somit liegt es im Ermessen des Kunden, diesen zu definieren gemäss den vorhanden Ressourcen auf der Agile Factory oder AnyCloudK8s.
Die Memory Quota muss gedacht ausgewählt werden, da es die Applikationen zum Abstürzen bringen kann, wenn dieser zu knapp gewählt wird
KubeConfig
Jeder Container Namespace hat einen Service Account. Dieser Account kann mit unterschiedlicher Berechtigung bestellt werden. Entweder als Admin Service Account oder als Viewer. Zusätzlich zum Service Account, wird auch ein Token erstellt, welches nach der Ablaufzeit des definierten "Time to Live" abläuft. Die Definition, ob die Berechtigung Admin oder Viewer sein soll, kann nur bei der Erstellung des Container Namespace eingestellt werden.
Das KubeConfig kann angezeigt und kopiert werden. Sollte die KubeConfig abgelaufen sein (erreichen der Time to Live) kann es erneuert werden. So ist sichergestellt, dass die Berechtigung auf den Namespace nicht immer die gleichen Credentials hat.
Der Container Namespace kann nur auf dem Target Cluster gelöscht werden, wenn er mit Admin Rechte bestellt wurde
Annotations/Labels
Das Feature ermöglicht das Setzen von Labels und Annotations beim Erstellen und Verwalten von Namespaces, was die Automatisierung und Transparenz im Cluster fördert.
Labels ermöglichen eine klare und strukturierte Kategorisierung von Namespaces, z. B. nach Teamzugehörigkeit, Umgebung oder Applikationstyp. Annotations bieten die Möglichkeit, zusätzliche Metadaten wie Beschreibungen, Verantwortlichkeiten oder betriebsrelevante Informationen zu hinterlegen.
Der Key eines Labels oder einer Annotation kann nach dem Erstellen nicht mehr geändert werden. Der zugehörige Value hingegen lässt sich jederzeit anpassen.