Informationen zum Entwerfen einer Kubernetes-Topologie in der Cloud

Unternehmen stellen immer immer immer native Cloud-Workloads in leichten Containern bereit. In einer Produktionsumgebung benötigen Sie eine Möglichkeit, die Container zu verwalten und sicherzustellen, dass es keine Ausfallzeit gibt. Kubernetes ist eine Open-Source-Orchestrierungs-Engine zur Verwaltung von containerisierten Anwendungen und Services.

Oracle Cloud Infrastructure Container Engine for Kubernetes ist ein verwalteter, skalierbarer und hochverfügbarer Service, mit dem Sie Ihre containerisierten Anwendungen für Kubernetes-Cluster in der Cloud bereitstellen können.

Architektur

Die Architektur einerKubernetes-basierten Topologie in der Cloud hängt von Faktoren ab, wie der Zugriff auf containerisierte Workloads über das öffentliche Internet, die Größe und die Anzahl der Knotenpools sowie die Anforderungen der Fehlertoleranz Ihrer Workloads.

Das folgende Diagramm zeigt eine Referenzarchitektur eines Kubernetes-Clusters in einer Oracle Cloud Infrastructure-Region, die mehrere Availability-Domains enthält.

Die Architektur enthält die folgenden Komponenten:

• Virtuelles Cloud-Netzwerk (VCN): Alle Ressourcen in der Topologie befinden sich in einem einzelnen VCN.
• Subnetze:

  VCN in dieser Architektur enthält vier Subnetze, zwei öffentliche und zwei private Subnetze. Eines der öffentlichen Subnetze ist für den Bastion-Host bestimmt; dies gilt auch für den Internet-seitigen Load Balancer. Von den beiden privaten Subnetzen gilt eines für einen Admin-Host, der das Tooling enthält, das zur Verwaltung des Kubernetes-Clusters erforderlich ist. Das andere private Subnetz ist für die Knoten des Kubernetes-Clusters bestimmt.

  Alle Subnetze sind regional, d.h. sie umfassen alle Availability-Domains in der Region, abgekürzt als AD1, AD2 und AD3 im Architekturdiagramm. Sie werden daher vor dem Ausfall der Availability-domain geschützt. Sie können die Subnetze für Ressourcen verwenden, die Sie für jede Availability-Domain in der Region bereitstellen.

• Netzwerk-Gateways
  • Servicegateway (optional)

    Das Servicegateway ermöglicht es Ressourcen in VCN, auf Oracle-Services wie Oracle Cloud Infrastructure Object Storage, Oracle Cloud Infrastructure File Storage und Oracle Cloud Infrastructure Database private zuzugreifen, d.h. ohne den Datenverkehr für das öffentliche Internet anzugeben. Verbindungen über dem Servicegateway können von den Ressourcen in VCN initiiert werden und nicht von den Services, mit denen die Ressourcen kommunizieren.

  • NAT-Gateway (optional)

    Mit dem NAT-Gateway können Compute-Instanzen, die privaten Subnetzen in VCN zugeordnet sind, auf das öffentliche Internet zugreifen. Verbindungen über das NAT-Gateway können aus den Ressourcen innerhalb von VCN und nicht aus dem öffentlichen Internet initiiert werden.

  • Internetgateway

    Das Internetgateway ermöglicht die Konnektivität zwischen dem öffentlichen Internet und allen Ressourcen in öffentlichen Subnetzen innerhalb von VCN.

• Bastion-Host (optional)

  Der Basishost ist eine Compute-Instanz, die als Einstiegspunkt für die Topologie außerhalb der Cloud dient.

  Der Bastion-Host wird normalerweise in einer DMZ bereitgestellt. Damit können Sie vertrauliche Ressourcen schützen, indem Sie sie in private Netzwerke platzieren, auf die nicht direkt aus der Cloud zugegriffen werden kann. Sie geben einen einzelnen, bekannten Einstiegspunkt an, der regelmäßig auditiert werden kann. Dadurch vermeiden Sie die Darstellung der sensibleren Komponenten der Topologie, ohne dass der Zugriff darauf beeinträchtigt wird.

  Der Basishost in der Beispieltopologie ist an ein öffentliches Subnetz angehängt und hat eine öffentliche IP-Adresse. Eine Ingress-Sicherheitsregel ist so konfiguriert, dass SSH-Verbindungen zum Bastion-Host über das öffentliche Internet zulässig sind. Um eine zusätzliche Sicherheitsebene bereitzustellen, können Sie den SSH-Zugriff auf den Bastion-Host nur aus einem bestimmten IP-Adressblock begrenzen.

  Sie können über den Bastion-Host auf Oracle Cloud Infrastructure-Instanzen in privaten Subnetzen zugreifen. Aktivieren Sie dazu die ssh-agent-Weiterleitung, mit der Sie eine Verbindung zum Bastion-Host herstellen und dann auf den nächsten Server zugreifen können, indem Sie die Zugangsdaten von Ihrem Rechner weiterleiten. Sie können auch mit dynamischem SSH-Tunneling auf die Instanzen im privaten Subnetz zugreifen. Der dynamische Tunnel stellt einen SOCKS-Proxy auf dem lokalen Port bereit, die Verbindungen stammen jedoch vom Remote-Host.

• Load Balancer-Knoten:

  Die Load Balancer-Knoten bestimmen und verteilen den Traffic an die verfügbaren Kubernetes-Knoten, auf denen die containerisierten Anwendungen ausgeführt werden. Wenn die Anwendungen über das öffentliche Internet zugänglich sein müssen, verwenden Sie öffentliche Load Balancer. Verwenden Sie andernfalls private Load Balancer, die keine öffentliche IP-Adresse haben. Die Architektur zeigt zwei Load Balancer-Knoten, jeweils in einer eindeutigen Availability-Domain.

• Admin-Host (optional):

  Mit einem Admin-Host können Sie die Installation und Ausführung von Infrastrukturtools wie kubectl, helm und der Oracle Cloud Infrastructure-CLI außerhalb der Cloud vermeiden. In der Referenzarchitektur befindet sich der Admin-Host in einem privaten Subnetz und kann über den Bastion-Host aufgerufen werden. Um die Oracle Cloud Infrastructure-CLI auf dem Admin-Host ausführen zu können, müssen Sie sie als Instanz-Principal angeben.

• Kubernetes Worker-Knoten:

  Die Kubernetes Worker-Knoten sind die Compute-Instanzen, auf denen Sie die containerisierten Anwendungen bereitstellen können. Alle Worker-Knoten in dieser Referenzarchitektur befinden sich in einem einzigen Knotenpool und sind an ein privates Subnetz angehängt. Bei Bedarf können Sie mehrere Knotenpools erstellen.

  Auf die Mitarbeiterknoten in der Referenzarchitektur kann nicht direkt über das öffentliche Internet zugegriffen werden. Benutzer der containerisierten Anwendungen können über den Load Balancer auf sie zugreifen. Administratoren können über den Bastion-Host auf die Mitarbeiterknoten zugreifen.

  Die Architektur zeigt drei Worker-Knoten, jeweils in einer eindeutigen Availability-Domain innerhalb der Region: AD1, AD2 und AD3. Die Kubernetes-Masterknoten werden inOracle-Mandanten ausgeführt und nicht angezeigt.

Wenn die Region, in der Sie die containerisierten Anwendungen bereitstellen möchten, eine einzige Availability-Domain enthält, werden die Worker-Knoten über die Faultdomains (FD) in der Availability-Domain verteilt, wie in der folgenden Architektur dargestellt.

Info zu erforderlichen Services und Berechtigungen

Diese Lösung erfordert die folgenden Services und Berechtigungen:

Service	Erforderliche Berechtigungen
Oracle Cloud Infrastructure Identity and Access Management	Dynamische Gruppen und Policys verwalten.
Oracle Cloud Infrastructure Networking	VCNs, Subnetze, Internetgateways, NAT-Gateways, Servicegateways, Routentabellen und Sicherheitslisten verwalten.
Oracle Cloud Infrastructure Compute	Compute-Instanzen verwalten.
Oracle Cloud Infrastructure Container Engine for Kubernetes	Cluster und Knotenpools verwalten. Siehe Policy-Konfiguration für Clustererstellung und -Deployment.