Weitere Informationen zum Einrichten eines Kubernetes-Clusters in der Cloud

EineKubernetes-basierte Topologie in der Cloud enthält zahlreiche Komponenten, einschließlich Netzwerkressourcen, Compute-Instanzen und Kubernetes-Knoten. Um eine derartige Topologie effizient bereitzustellen und zu verwalten, definieren Sie Ihre Cloud-Infrastruktur als Code (IaC) in den Terraform-Konfigurationsdateien.

Um die Topologie zu ändern, versionieren Sie die entsprechenden Terraform-Module, aktualisieren Sie die Ressourcendefinitionen, und wenden Sie die überarbeitete Konfiguration an. Bei Bedarf können Sie jederzeit auf eine vorherige Version der Infrastruktur zurücksetzen.

Mit den in dieser Lösung bereitgestellten Terraform-Builder-Blöcken können Sie die für eine cloud-basierte Kubernetes-Umgebung erforderliche Infrastruktur bereitstellen.

Bevor Sie beginnen

Bevor Sie mit dem Erstellen der Kubernetes-Topologie in Oracle Cloud beginnen, erfahren Sie mehr über die Architekturoptionen und die Komponenten der Architektur.

Weitere Informationen zum Entwerfen einer Kubernetes-Topologie für containerisierte Anwendungen in der Cloud.

Architektur

Die Beispieltopologie, für die diese Lösung Terraform-Code bereitstellt, enthält ein einzelnes virtuelles Cloud-Netzwerk (VCN) mit den erforderlichen Netzwerk- und Kubernetes-Ressourcen, alle in einer einzelnen Oracle Cloud Infrastructure-Region.

Die Architektur besteht aus den folgenden Komponenten.

Hinweis:

Der Terraform-Code umfasst Eingabevariablen, mit denen Sie die Architektur an die Netzwerkanforderungen Ihrer containerisierten Workloads anpassen können, die Größe und Anzahl der erforderlichen Knotenpools, die Fehlertoleranz-Constraints usw.

Virtuelles Cloud-Netzwerk (VCN)
Alle Ressourcen in der Topologie befinden sich in einem Netzwerk. Sie definieren das CIDR-Präfix für das Netzwerk (Standard: 10.0.0.0/16).

Subnetze

Die VCN in der Beispieltopologie enthält vier Subnetze. Sie definieren die Größe der Subnetze.

Subnetz	Standard-CIDR-Präfix	Beschreibung
Bastion-Subnetz	10.0.1.0/29	Ein öffentliches Subnetz für den optionalen Bastion-Host.
Load Balancer-Subnetz	10.0.2.32/27 falls öffentlich (10.0.2.0/27, wenn privat)	Ein Subnetz für die Load Balancer-Knoten. Sie wählen, ob das Subnetz öffentlich oder privat ist.
Admin-Subnetz	10.0.1.8/29	Ein privates Subnetz für den optionalen Admin-Host, das die zur Verwaltung des Kubernetes-Clusters erforderlichen Tools wie `kubectl`, `helm` und die Oracle Cloud Infrastructure-CLI enthält.
Worker-nodes Subnetz	10.0.64.0/18	Ein Subnetz für die Kubernetes-Mitarbeiterknoten. Sie wählen, ob das Subnetz öffentlich oder privat ist.

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 ein regionales Subnetz für die Ressourcen verwenden, die Sie in einer beliebigen 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 (nicht im Beispielcode enthalten)
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. In der Architektur werden keine Load Balancer-Knoten angezeigt.
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. Der Admin-Host in der Beispieltopologie befindet sich 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. In der Beispieltopologie sind alle Mitarbeiterknoten in einem einzigen Knotenpool enthalten und sind an ein privates Subnetz angehängt. Sie können die Anzahl der Knotenpools, die Größe jedes Pools und die Verwendung eines öffentlichen Subnetzes je nach Anforderungen anpassen.

Wenn die Mitarbeiterknoten an ein privates Subnetz angehängt sind, kann nicht direkt über das öffentliche Internet darauf zugegriffen werden. Benutzer können über den Load Balancer auf die containerisierten Anwendungen zugreifen.

Wenn Sie den SSH-Zugriff auf die Mitarbeiterknoten aktivieren, können Administratoren über den Basishost SSH-Verbindungen erstellen.

Die Architektur zeigt drei Worker-Knoten, jeweils in einer eindeutigen Availability-Domain innerhalb der Region: AD1, AD2 und AD3.

Hinweis:
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) innerhalb der Availability-Domain verteilt.

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.