Auch im Bereich Cloud Hosting von Atlassian Software mit AWS oder Spinnaker bietet es sich an, dediziertes Projekt und User Management zu haben. Für Kubernetes gibt mehrere Möglichkeiten, die Projekt- und Benutzerverwaltung zu handhaben:

  1. Man kann mehrere EKS-Cluster einrichten und sie auf diese Weise voneinander trennen:
    • Dies ist zunächst eine einfache und saubere Lösung, da man keinen Weg finden muss, um Ressourcen und Berechtigungen zu trennen.
    • Wenn diese Cluster unabhängig voneinander verwaltet werden sollen und wahrscheinlich unabhängige Anwendungen bereitstellen, kann dies ein gültiger Ansatz sein.
    • Wenn die Cluster stattdessen zentral verwaltet werden sollen, verursacht dies eine Menge administrativen Aufwand und erfordert eine weitere Logikschicht, um Deployment-Pipelines, Benutzerrechte und weitere Automatismen zu implementieren.
  2. Ein einzelner EKS-Cluster kann die Projekt- und Benutzerverwaltung mit nativen Kubernetes-Funktionen handhaben.
    1. Projekte können in verschiedenen Namespaces verwaltet werden:
    2. Deployments können durch umfangreiches Tagging getrennt werden.
    3. Kubernetes bietet die Möglichkeit, Rollen mit dedizierten Berechtigungen auf Kubernetes-Ressourcen einzurichten, auf die Benutzer und Ressourcen zugreifen können, um eine feingranulare Rechteverwaltung zu ermöglichen
    4. Mit diesem Konzept können natürlich zusätzlich weitere Cluster eingerichtet werden, zum Beispiel für Projekte mit abweichenden Konfigurationen oder für Kubernetes-Updates.

Beide Optionen sind legitim und es kommt darauf an, wie Sie den/die Cluster in Zukunft administrieren wollen.

Netzwerk/ DNS

Die Compute Nodes selbst sind über ein anderes Netzwerk miteinander und mit dem Master verbunden. Damit eine in Kubernetes bereitgestellte Anwendung von außerhalb des Clusters erreichbar ist, muss ein Ingress bereitgestellt werden, der als Tor außerhalb des Clusters fungiert.

Innerhalb des Clusters ist es für jeden Pod immer möglich, sich mit einem anderen Pod zu verbinden. Das liegt daran, dass Kubernetes sein eigenes Netzwerk erzeugt, in dem alle Deployments stattfinden. Jeder Pod innerhalb von Kubernetes erhält eine eigene IP-Adresse.

Vernetzung innerhalb Kubernetes

Wie die Vernetzung innerhalb von Kubernetes funktioniert, hängt stark davon ab, welche Netzwerk-Plugins und welcher Ingress-Controller installiert ist. Dadurch wird sichergestellt, dass die Umgebung innerhalb von Kubernetes auf die Anforderungen der Anwendung zugeschnitten werden kann.

EKS ist in der Lage, je nach installiertem Ingress-Controller verschiedene Arten von Loadbalancern zu spawnen. Hier empfiehlt es sich, einen externen DNS-Dienst zu verwenden und damit sicherzustellen, dass mindestens ein Pod immer über diesen DNS-Namen erreicht werden kann, um maximal ausfallsicher zu sein.

Netzwerk/ DNS

Die Compute Nodes selbst sind über ein anderes Netzwerk miteinander und mit dem Master verbunden. Damit eine in Kubernetes bereitgestellte Anwendung von außerhalb des Clusters erreichbar ist, muss ein Ingress bereitgestellt werden, der als Tor außerhalb des Clusters fungiert. Innerhalb des Clusters ist es für jeden Pod immer möglich, sich mit einem anderen Pod zu verbinden. Das liegt daran, dass Kubernetes sein eigenes Netzwerk erzeugt, in dem alle Deployments stattfinden. Jeder Pod innerhalb von Kubernetes erhält eine eigene IP-Adresse.

Wie die Vernetzung innerhalb von Kubernetes funktioniert, hängt stark davon ab, welche Netzwerk-Plugins und welcher Ingress-Controller installiert ist. Dadurch wird sichergestellt, dass die Umgebung innerhalb von Kubernetes auf die Anforderungen der Anwendung zugeschnitten werden kann.

EKS ist in der Lage, je nach installiertem Ingress-Controller verschiedene Arten von Loadbalancern zu spawnen. Hier empfiehlt es sich, einen externen DNS-Dienst zu verwenden und damit sicherzustellen, dass mindestens ein Pod immer über diesen DNS-Namen erreicht werden kann, um maximal ausfallsicher zu sein.

Spinnaker

Für die Bereitstellungsebene wird in diesem Konzept Spinnaker verwendet. Spinnaker ist eine Deployment-Software, die für Massen- und standardisierte Deployments von containerisierten Anwendungen in Kubernetes entwickelt wurde.

Hier ist es möglich, verschiedene Input-Quellen zu definieren, Pipelines zu erstellen, um Deployments zu automatisieren und Regeln/ Checks für Pipelines zu definieren, um die Integrität der gesamten Umgebung zu erhöhen.

Es ist auch möglich und empfehlenswert, in dieser Phase Deployment-Fallbacks zu implementieren, wie z. B. ein Blue-Green-Deployment und Versionierung für Anwendungs-Deployments. Hier ist eine kleine Skizze, um zu sehen, wie Spinnaker Anwendungen bereitstellt:

Spinnaker, Kubernetes und Projektmanagement

Spinnaker kann natürlich weit mehr als nur Pipelines und Deployments erstellen. Es kommt auch mit einer einfach zu bedienenden Web-UI, um Ihnen einen transparenten Überblick über die verschiedenen Deployments und Projekte in Kubernetes zu geben. Mit ein paar Klicks können Sie diese ändern.

Vorteile von Spinnaker:

  • Standardisiert.
  • Zukunftssicher.
  • Schnelle Deployments.
  • Schnelles Rollback.
  • Hoher Deployment-Durchsatz.
  • Sehr hoher Automatismus.
  • Geringer administrativer Aufwand nach der Implementierung.
  • Nahtloser Wechsel zu neuen Deployment-Workflows.
  • Cloud-Provider-Wechsel möglich.

Nachteile von Spinnaker:

  • Deployment-Workflow muss gut durchdacht sein.
  • Hoher initialer Administrationsaufwand.
  • Mehrere neue Anwendungen und Logikschichten müssen vom Betrieb verstanden und gelernt werden.
  • Funktioniert nur mit containerisierten Umgebungen.

← Zurück zu Teil 2: Deployment