Containers Anatomy 101: Was ist ein Cluster?

Aus Netzwerksicht erweitern Container den Netzwerk-"Edge“ — die Grenze zwischen Entscheidungen zur Netzwerkweiterleitung und dem Erreichen des Endziels eines Pakets — tief in den Host hinein. Der Edge ist nicht mehr die Netzwerkschnittstelle eines Hosts, sondern besteht aus mehreren Ebenen, die tief in logischen Konstrukten innerhalb eines Hosts verankert sind. Und die Netzwerktopologie ist abstrahiert und reicht tief in diese logischen Konstrukte innerhalb eines Hosts hinein, und zwar in Form von Overlay-Netzwerktunneling, virtuellen Schnittstellen, NAT-Grenzen, Load Balancern und Netzwerk-Plugins. Netzwerk- und Sicherheitsarchitekten können Betriebssysteminterna beim Entwurf ihrer Architekturen nicht länger ignorieren. Container zwingen diese Architekturen dazu, zu verstehen, wohin ein Paket geht, nachdem es die Netzwerkkarte eines Hosts passiert hat.

Orchestrierungssysteme

Vor diesem Hintergrund ist ein Orchestrierungssystem erforderlich, um eine gewisse Form von Ordnung in Container-Umgebungen zu bringen. Ein Orchestrierungssystem verwaltet die Details rund um die Organisation, Skalierung und Automatisierung von Containern und erstellt logische Konstrukte rund um verschiedene Komponenten, die für das Verhalten von Containern relevant sind. Sie sind auch dafür verantwortlich, die logischen Grenzen, die den Container-Laufzeiten zugeordnet sind, zu organisieren und logische Konstrukte zu erstellen, denen eine IP-Adresse zugewiesen werden kann. Allerdings sind solche Systeme extern und können den Lebenszyklus bestimmter Container-Laufzeitinstanzen, die beispielsweise immer noch von Docker verwaltet werden, nicht bereitstellen und verwalten.

Es gibt viele Container-Orchestrierungssysteme, aber die beiden heute am häufigsten verwendeten sind Kubernetes und OpenShift. Beide verfolgen dieselben grundlegenden Ziele, wobei der Hauptunterschied darin besteht, dass das eine ein Projekt und das andere ein Produkt ist: Kubernetes ist ein Projekt, das größtenteils aus Google hervorgegangen ist, und OpenShift ist ein Produkt von Red Hat. Im Allgemeinen wird Kubernetes am häufigsten in öffentlichen Cloud-Umgebungen eingesetzt, und OpenShift kommt am häufigsten in Rechenzentren vor Ort zum Einsatz, aber es gibt erhebliche Überschneidungen zwischen den beiden. Kurz gesagt, Kubernetes liegt beiden Ansätzen zugrunde, wobei es einige geringfügige Unterschiede in der Terminologie zwischen den beiden gibt.

Eine kurze Geschichte der Container

Ob Sie es glauben oder nicht, Container sind älter als Kubernetes. Docker zum Beispiel veröffentlichte seine Container-Plattform erstmals 2013, wohingegen Kubernetes sein auf die öffentliche Cloud ausgerichtetes Projekt erst 2014 veröffentlichte. OpenShift wurde vor beiden eingeführt, wobei der Schwerpunkt auf Hosts lag, die in Rechenzentren vor Ort eingesetzt wurden.

Die einfache Bereitstellung von Container-Laufzeiten auf einem lokalen Host entspricht in der Regel den Bedürfnissen der Entwickler, da Runtimes über „localhost“ und eindeutige Ports miteinander kommunizieren können. Container-Laufzeiten werden keine bestimmten IP-Adressen zugewiesen. Wenn Sie sich darauf konzentrieren, schnellen und effizienten Code zu schreiben und Ihre Anwendung für eine Sammlung von zugehörigen Container-Laufzeiten bereitzustellen, funktioniert dieser Ansatz einwandfrei. Wenn Sie jedoch möchten, dass diese Anwendung auf externe Ressourcen außerhalb des lokalen Hosts zugreift, oder wenn Sie möchten, dass externe Clients auf diese Anwendung zugreifen, können Sie die Netzwerkdetails nicht ignorieren. Dies ist einer der Gründe, warum ein Orchestrierungssystem benötigt wird.

Kubernetes basiert auf einer Reihe von Bausteinen und einem API-gesteuerten Workflow, um das Verhalten von Container-Laufzeiten zu organisieren. Bei diesem Ansatz erstellt Kubernetes eine Reihe logischer Konstrukte innerhalb und zwischen Hosts, die einer bestimmten containerisierten Umgebung zugeordnet sind, und erstellt ein völlig neues Vokabular, das sich auf diese Konstrukte bezieht. Kubernetes wendet diese Bausteine und API-gesteuerten Workflows zwar auf eine Reihe von Rechenmetriken an, die mit der CPU-Zuweisung, den Speicheranforderungen und anderen Metriken wie Speicher, Authentifizierung und Messung zusammenhängen, aber die meisten Sicherheits- und Netzwerkexperten konzentrieren sich auf eine Sache:

Welche Grenzen durchläuft ein IP-Paket auf dem Weg zu einem logischen Konstrukt, dem eine IP-Adresse zugewiesen ist?

Aus Netzwerksicht erstellen sowohl Kubernetes als auch OpenShift logische, relevante Konstrukte in einem hierarchischen Ansatz, wobei sich das Vokabular zwischen den einzelnen Systemen nur geringfügig unterscheidet. Dies wird unten veranschaulicht.

Das ABC eines Container-Clusters

Dieses Diagramm zeigt das grundlegende logische Konstrukt einer Kubernetes-Umgebung. Es erklärt nicht, was die einzelnen Konstrukte tun, sondern nur, wie sie logisch zueinander in Beziehung stehen.

Ausgehend vom breitesten Konstrukt bis hin zum kleinsten finden Sie hier kurze Erklärungen:

• Cluster: Ein Cluster ist die Sammlung von Hosts, die einer bestimmten containerisierten Bereitstellung zugeordnet sind.
• Knoten: Innerhalb eines Clusters gibt es Knoten. Ein Knoten ist der Host, auf dem sich Container befinden. Ein Host kann entweder ein physischer Computer oder eine VM sein und er kann sich entweder in einem lokalen Rechenzentrum oder in einer öffentlichen Cloud befinden. Im Allgemeinen gibt es zwei Kategorien von Knoten in einem Cluster: die „Master-Knoten“ und die „Worker-Knoten“. Der Einfachheit halber ist ein Master-Knoten die Steuerungsebene, die die zentrale Datenbank des Clusters und des API-Servers bereitstellt. Die Worker-Knoten sind die Maschinen, auf denen die echten Anwendungs-Pods ausgeführt werden.
• Hülsen: In jedem Knoten erstellen sowohl Kubernetes als auch OpenShift Pods. Jeder Pod umfasst entweder eine oder mehrere Container-Laufzeiten und wird vom Orchestrierungssystem verwaltet. Pods werden von Kubernetes und OpenShift IP-Adressen zugewiesen.
• Behälter: In den Pods befinden sich die Container-Runtimes. Container innerhalb eines bestimmten Pods haben alle dieselbe IP-Adresse wie dieser Pod, und sie kommunizieren über Localhost miteinander, wobei sie eindeutige Ports verwenden.
• Namespace: Eine bestimmte Anwendung wird „horizontal“ über mehrere Knoten in einem Cluster bereitgestellt und definiert eine logische Grenze für die Zuweisung von Ressourcen und Berechtigungen. Pods (und damit Container) und Dienste, aber auch Rollen, Geheimnisse und viele andere logische Konstrukte gehören zu einem Namespace. OpenShift nennt das ein Projekt, aber es ist dasselbe Konzept. Im Allgemeinen ist ein Namespace einer bestimmten Anwendung zugeordnet, die in allen zugehörigen Containern eingesetzt wird. Ein Namespace hat nichts mit einem Netzwerk- und Sicherheitskonstrukt zu tun (anders als ein Linux-IP-Namespace)
• Bedienung: Da Pods kurzlebig sein können — sie können plötzlich verschwinden und später dynamisch erneut bereitgestellt werden — ist ein Service ein „Frontend“, das vor einer Reihe von zugehörigen Pods bereitgestellt wird und wie ein Load-Balancer mit einem VIP funktioniert, der nicht verschwindet, wenn ein Pod verschwindet. Ein Service ist ein nicht kurzlebiges logisches Konstrukt mit einer eigenen IP-Adresse. Mit nur wenigen Ausnahmen innerhalb von Kubernetes und OpenShift verweisen externe Verbindungen auf die IP-Adresse eines Dienstes und werden dann an „Backend“ -Pods weitergeleitet.
• Kubernetes-API-Server: Hier wird der API-Workflow zentralisiert, wobei Kubernetes die Erstellung und den Lebenszyklus all dieser logischen Konstrukte verwaltet.

Sicherheitsherausforderungen bei Containern

Um Sicherheitssegmente entlang der Workload-Grenzen zu erstellen, ist es notwendig, diese grundlegenden logischen Konstrukte zu verstehen, die von Kubernetes erstellt wurden. Externer Netzwerkverkehr, der in die gehostete Anwendung ein- und ausgeht, verweist in der Regel nicht auf die IP-Adresse des zugrundeliegenden Hosts, des Nodes. Stattdessen wird der Netzwerkverkehr entweder auf einen Dienst oder einen Pod innerhalb dieses Hosts verweisen. Daher müssen die mit einem Workload verbundenen Dienste und Pods ausreichend verstanden werden, um eine effektive Segmentierungs-Sicherheitsarchitektur.

Interessiert an mehr? Auschecken unser Artikel über die Herausforderungen netzwerkbasierter Ansätze zur Container-Segmentierung und wie diese mithilfe von hostbasierter Segmentierung überwunden werden können.