Serverloses Kubernetes mit virtuellen Knoten der OCI Kubernetes Engine bereitstellen
Beide Betriebsarten können grundlegende Anwendungen bis zu den geschäftskritischsten unterstützen. Mit virtuellen Knoten werden die Kubernetes-Vorgänge vereinfacht und bieten das beste Preis-Leistungs-Verhältnis. Der Kompromiss zwischen verwalteten und virtuellen Knoten besteht bei verwalteten Knoten. Sie haben mehr Kontrolle über Ihre Knoteninfrastruktur. Sie können Ihre Kubernetes-Ressourcen so konfigurieren, dass sie HostPort
und HostNetwork
verwenden, oder Sie können DaemonSets
und andere Optionen ausführen, die möglicherweise für Ihre Anwendungen oder Tools erforderlich sind. In den meisten Anwendungsfällen sind diese Optionen nicht erforderlich.
Virtuelle Knoten sind am sinnvollsten, wenn Sie die Kontrolle über das Ausführen und Verwalten Ihrer Container nicht optimieren müssen. Wenn Ihre Anwendungen eine Konfiguration der Knoteninfrastruktur erfordern, die für virtuelle Knoten nicht verfügbar ist, verwenden Sie verwaltete Knoten.
Architektur
Um das OKE-Cluster in OCI Vault zu integrieren, wird der externe Secrets-Operator im OKE-Cluster bereitgestellt. Dadurch können Sie eine SecretStore-Ressource definieren, die dem OCI Vault zugeordnet ist, um das Kennwort für die Datenbank zu speichern. Nachdem die Ressource SecretStore zugeordnet wurde, kann das OKE-Cluster als Kubernetes-Secret auf das Kennwort zugreifen. Mit einer OCI Identity and Access Management-Rolle mit Leseberechtigung für den OCI Vault kann der Pod auf das Secret zugreifen. Die Rolle ist mit dem Kubernetes-Serviceaccount verknüpft, der in der Poddefinition verwendet wird, um ihm Zugriff zum Lesen aus dem OCI Vault zu erteilen.
Das folgende Diagramm veranschaulicht diese Referenzarchitektur.

Beschreibung der Abbildung k8n-virtual-nodes.png
k8n-virtuelle Knoten-oracle.zip
Die Architektur umfasst die folgenden Komponenten:
- Tenancy
Ein Mandant ist eine sichere und isolierte Partition, die Oracle in Oracle Cloud einrichtet, wenn Sie sich für Oracle Cloud Infrastructure registrieren. Sie können Ihre Ressourcen in Oracle Cloud in Ihrem Mandanten erstellen, organisieren und verwalten. Ein Mandant ist ein Synonym für ein Unternehmen oder eine Organisation. In der Regel verfügt ein Unternehmen über einen einzigen Mandanten und spiegelt seine Organisationsstruktur innerhalb dieses Mandanten wider. Ein einzelner Mandant ist in der Regel mit einem einzelnen Abonnement verknüpft, und ein einzelnes Abonnement hat in der Regel nur einen Mandanten.
- Region
Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center enthält, das als Availability-Domain bezeichnet wird. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).
- Compartment
Compartments sind regionsübergreifende logische Partitionen innerhalb eines Oracle Cloud Infrastructure-Mandanten. Mit Compartments können Sie Ihre Ressourcen in Oracle Cloud organisieren, den Zugriff auf die Ressourcen kontrollieren und Nutzungs-Quotas festlegen. Um den Zugriff auf die Ressourcen in einem bestimmten Compartment zu kontrollieren, definieren Sie Policys, mit denen angegeben wird, wer auf die Ressourcen zugreifen kann und welche Aktionen sie ausführen können.
- Availability-Domains
Availability-Domains sind eigenständige, unabhängige Data Center innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz sicherstellt. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domainnetzwerk. Daher sollte ein Fehler in einer Availability-Domain sich nicht auf die anderen Availability-Domains in der Region auswirken.
- Faultdomains
Eine Faultdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain umfasst drei Faultdomains mit unabhängiger Stromversorgung und Hardware. Wenn Sie Ressourcen auf mehrere Faultdomains verteilen, können Ihre Anwendungen physische Serverausfälle, Systemwartungen und Stromausfälle innerhalb einer Faultdomain tolerieren.
- Virtuelles Cloud-Netzwerk (VCN) und Subnetze
Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten können. Wie herkömmliche Data Center-Netzwerke erhalten Sie mit VCNs die Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.
- Load Balancer
Der Oracle Cloud Infrastructure Load Balancing-Service ermöglicht automatisierte Trafficverteilung von einem einzelnen Einstiegspunkt auf mehrere Server im Backend.
- Internetgateway
Das Internetgateway ermöglicht Traffic zwischen den öffentlichen Subnetzen in einem VCN und dem öffentlichen Internet.
- Network Address Translation-(NAT-)Gateway
Ein NAT-Gateway ermöglicht privaten Ressourcen in einem VCN den Zugriff auf Hosts im Internet, ohne dass diese Ressourcen für eingehende Internetverbindungen freigegeben werden.
- Servicegateway
Das Servicegateway bietet Zugriff von einem VCN auf andere Services, wie Oracle Cloud Infrastructure Object Storage. Der Traffic vom VCN zum Oracle-Service wird über die Oracle-Netzwerkstruktur geleitet und durchläuft nicht das Internet.
- Vault
Mit Oracle Cloud Infrastructure Vault können Sie die Verschlüsselungsschlüssel, die Ihre Daten schützen, und die Secret-Zugangsdaten, mit denen Sie den Zugriff auf Ihre Ressourcen in der Cloud sichern, zentral verwalten. Mit dem Vault-Service können Sie Vaults, Schlüssel und Secrets erstellen und verwalten.
- Registrierung
Oracle Cloud Infrastructure Registry ist eine von Oracle verwaltete Registry, mit der Sie Ihren Workflow von der Entwicklung bis zur Produktion vereinfachen können. Die Registry erleichtert Ihnen das Speichern, Freigeben und Verwalten von Entwicklungsartefakten wie Docker-Images. Die hochverfügbare und skalierbare Architektur von Oracle Cloud Infrastructure stellt sicher, dass Sie Ihre Anwendungen zuverlässig bereitstellen und verwalten können.
- Sicherheitsliste
Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Typ des Traffics angeben, der im Subnetz und aus dem Subnetz zugelassen werden muss.
- Routentabelle
Virtuelle Routentabellen enthalten Regeln zum Weiterleiten von Traffic von Subnetzen an Ziele außerhalb eines VCN, in der Regel über Gateways.
- OCI Kubernetes Engine
Oracle Cloud Infrastructure Kubernetes Engine (Kubernetes Engine oder OKE) ist ein vollständig verwalteter, skalierbarer und hoch verfügbarer Service, mit dem Sie Ihre Containeranwendungen in der Cloud bereitstellen können. Sie geben die Compute-Ressourcen an, die Ihre Anwendungen benötigen, und Kubernetes Engine stellt sie in Oracle Cloud Infrastructure in einem vorhandenen Mandanten bereit. OKE automatisiert mit Kubernetes das Deployment, die Skalierung und die Verwaltung containerisierter Anwendungen über Cluster von Hosts hinweg.
- Oracle MySQL Database Service
Oracle MySQL Database Service ist ein vollständig verwalteter Oracle Cloud Infrastructure-(OCI-)Datenbankservice, mit dem Entwickler schnell sichere, Cloud-native Anwendungen entwickeln und bereitstellen können. Oracle MySQL Database Service wurde für OCI optimiert und ist exklusiv in OCI verfügbar und wird zu 100% von den OCI- und MySQL-Entwicklungsteams erstellt, verwaltet und unterstützt.
Oracle MySQL Database Service verfügt über eine integrierte, leistungsstarke Analyse-Engine (HeatWave), mit der anspruchsvolle Echtzeitanalysen direkt für eine betriebliche MySQL-Datenbank ausgeführt werden können.
- Ingress-Controller
Ein Ingress-Controller (ing) ist eine Komponente, die in einem Kubernetes-Cluster ausgeführt wird und die Ingress-Ressourcen verwaltet. Er empfängt Traffic vom externen Netzwerk, leitet ihn an den richtigen Service weiter und führt Load Balancing und SSL-Beendigung durch. Der Ingress-Controller wird in der Regel als separater Pod im Cluster ausgeführt und kann unabhängig von den von ihm verwalteten Services skaliert werden.
- Geheimnisse von Kubernetes
Kubernetes-Secrets können sensible Konfigurationsdaten wie Authentifizierungstoken, Kennwörter und SSH-Schlüssel enthalten. Mit Secrets können Sie sensible Daten kontrollieren und das Risiko verringern, dass die Daten nicht autorisierten Benutzern zugänglich gemacht werden. Oracle Container Engine for Kubernetes unterstützt die Verschlüsselung von Kubernetes-Secrets im Ruhezustand.
- Externer Secrets-Operator
Der Kubernetes External Secrets Operator integriert Oracle Container Engine for Kubernetes mit Oracle Cloud Infrastructure Vault. Der Operator liest Informationen aus externen APIs und fügt die Werte automatisch in ein Kubernetes-Secret ein.
- SecretStore
In der Kubernetes-Cluster-Control Plane werden sensible Konfigurationsdaten (wie Authentifizierungstoken, Zertifikate und Zugangsdaten) als Kubernetes-Secret-Objekte in
etcd
gespeichert.Etcd
ist ein Open-Source-verteilter Key-Value Store, den Kubernetes für die Clusterkoordination und Statusverwaltung verwendet. In den Kubernetes-Cluster, die von Container Engine for Kubernetes erstellt werden, schreibt und liestetcd
Daten in und aus Blockspeicher-Volumes im Oracle Cloud Infrastructure Block Volumes-Service. Standardmäßig verschlüsselt Oracle Daten in Block-Volumes im Ruhezustand, einschließlichetcd
und Kubernetes-Secrets. Oracle verwaltet diese Standardverschlüsselung mit einem Masterverschlüsselungsschlüssel, ohne dass Sie Maßnahmen ergreifen müssen. Für zusätzliche Kontrolle über den Lebenszyklus des Masterverschlüsselungsschlüssels und dessen Verwendung können Sie den Masterverschlüsselungsschlüssel selbst verwalten, anstatt ihn von Oracle für Sie verwalten zu lassen.Wenn Sie ein neues Cluster erstellen, können Sie angeben, dass Kubernetes-Secrets in
etcd
mit Oracle Key Management Cloud Service verschlüsselt werden sollen. - Pod
Ein Pod ist eine Gruppe von einem oder mehreren Containern und deren Shared Storage sowie alle spezifischen Optionen für die gemeinsame Ausführung dieser Container. Normalerweise teilen sich Container in einem Pod denselben Netzwerk- und Arbeitsspeicherplatz und können zur Speicherung auf gemeinsam genutzte Volumes zugreifen. Mit diesen gemeinsam genutzten Ressourcen können die Container in einem Pod nahtlos intern kommunizieren, als wären sie auf einem einzelnen logischen Host installiert.
- Virtueller Knoten
Ein virtueller Knoten ist eine Softwareabstraktion eines tatsächlichen Knotens. Virtuelle Knoten werden im Mandanten von OCI bereitgestellt und vollständig von OCI überwacht und verwaltet.
Empfehlungen
- VCN
Wenn Sie ein VCN erstellen, bestimmen Sie die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen, die Sie an Subnetze im VCN anhängen möchten. Verwenden Sie CIDR-Blöcke, die sich innerhalb des privaten IP-Standardadressraums befinden.
Wählen Sie CIDR-Blöcke aus, die sich nicht mit einem anderen Netzwerk (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider) überschneiden, zu dem Sie private Verbindungen einrichten möchten.
Nachdem Sie ein VCN erstellt haben, können Sie die CIDR-Blöcke ändern, hinzufügen und entfernen.
Berücksichtigen Sie beim Entwerfen der Subnetze Ihren Trafficfluss und Ihre Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Ebene oder Rolle an dasselbe Subnetz an, das als Sicherheitsgrenze dienen kann.
Verwenden Sie regionale Subnetze.
- Netzwerksicherheitsgruppen (NSGs)
Mit NSGs können Sie eine Gruppe von Ingress- und Egress-Regeln definieren, die für bestimmte VNICs gelten. Wir empfehlen die Verwendung von NSGs und nicht von Sicherheitslisten, da NSGs es Ihnen ermöglichen, die Subnetzarchitektur des VCN von den Sicherheitsanforderungen Ihrer Anwendung zu trennen.
Mit NSGs können Sie eine Gruppe von Ingress- und Egress-Regeln definieren, die für bestimmte VNICs gelten. Wir empfehlen die Verwendung von NSGs und nicht von Sicherheitslisten, da NSGs es Ihnen ermöglichen, die Subnetzarchitektur des VCN von den Sicherheitsanforderungen Ihrer Anwendung zu trennen.
- Load-Balancer-Bandbreite
Beim Erstellen des Load Balancers können Sie entweder eine vordefinierte Ausprägung auswählen, die eine feste Bandbreite bereitstellt, oder eine benutzerdefinierte (flexible) Ausprägung angeben, in der Sie einen Bandbreitenbereich festlegen und den Service die Bandbreite automatisch basierend auf Trafficmustern skalieren lassen. Bei beiden Verfahren können Sie die Ausprägung nach dem Erstellen des Load Balancers jederzeit ändern.
Hinweise
Beachten Sie Folgendes, wenn Sie mit virtuellen Knoten arbeiten.
Um mit virtuellen Knoten zu beginnen, müssen Sie zuerst ein OCI Kubernetes Engine-Cluster mit einem virtuellen Knotenpool erstellen oder einen virtuellen Knotenpool zu einem vorhandenen Kubernetes Engine-(OKE-)Cluster hinzufügen.
- Wählen Sie die Ausprägung und Platzierung der virtuellen Knoten aus.
-
Die Ausprägung bestimmt den Typ der Prozessoren sowie die Anzahl der CPU- und Speicherressourcen, die jedem Pod zugewiesen werden können. Jeder Pod kann bis zu den Speicher- und CPU-Grenzwerten der ausgewählten Ausprägung zuweisen.
-
Virtuelle Knoten skalieren Pods mit der Konfiguration von Horizontal Pod Autoscaler (HPA). Knoten Autoscaler muss nicht konfiguriert werden.
-
Sie können Ihre virtuellen Knoten in bestimmten Availability-Domains und Faultdomains platzieren, die am besten für Ihre High Availability-(HA-)Anforderungen geeignet sind. Platzieren Sie für die maximale Redundanzstufe einen virtuellen Knoten in jeder Faultdomain in der Availability-Domain des OKE-Clusters.
-
Verwenden Sie Kubernetes-Knotenlabels, um die Platzierung Ihrer Pods auf virtuellen Knoten anzugeben. Um eine gleichmäßige Verteilung von Pods über Knoten hinweg abzurufen, verwenden Sie das Constraint
PodTopologySpread
.
-
-
Virtuelle Knoten verwenden ein VCN-natives Podnetzwerk. Die Anzahl der im Cluster verfügbaren Pods ist durch die Anzahl der im Subnetz verfügbaren IP-Adressen begrenzt.
- Native Podnetworking bietet jedem Pod eine in den Subnetzen des VCN native IP-Adresse, mit der jeder Pod von integrierten OCI-Netzwerksicherheitsfunktionen wie VCN-Flowlogs, Routing-Policys, VTAP und Sicherheitsgruppen profitieren kann.
- Verwenden Sie einen Subnetzbereich, der die Anzahl der Pods und Knoten zulässt, die Sie voraussichtlich verwenden werden, und Platz für Wachstum bietet.
- Definieren Sie Netzwerksicherheitsgruppen (NSGs), um den Traffictyp zu begrenzen, der von den Pods in- und ausgehen kann.
- Mit VCN-Flowlogs können Sie den gesamten Netzwerktraffic zwischen Pods prüfen oder den Netzwerktraffic mit VTAP erfassen.
- Pods in virtuellen Knoten erhalten Zugriff auf andere OCI-Services mit Workload-Identität.
In bestimmten Fällen benötigt ein Pod möglicherweise Zugriff auf andere Services in OCI.
- Mit Workload Identity Berechtigungen für Pods in virtuellen Knoten erteilen Workload Identity verknüpft OCI Identity and Access Management-Rollen mit Kubernetes-Serviceaccounts, die Pods zugewiesen sind.
- Virtuelle Knoten bieten Isolation auf Hypervisor-Ebene für Ihren Pod.
Sicherheitslücken können es potenziell ermöglichen, dass böswillige Prozesse in einem Container "enthüllen" und den Kernel des Knotens beeinträchtigen und den Knoten möglicherweise herunterfahren. Der schädliche Code kann auch auf Daten im Speicher oder Speicher zugreifen und die Daten exfiltrieren. Die exfiltrierten Daten können möglicherweise zu einem anderen Mandanten in einer Mehrmandantenumgebung gehören.
- Der virtuelle Knoten bietet eine Isolation auf Hypervisor-Ebene für Ihre Pods. Ein Pod teilt Compute-, Speicher- und Netzwerkressourcen nicht mit anderen Pods im Cluster, sodass die Möglichkeit eines ausgefallenen Knotens oder exfiltrierter Daten, die zu einem anderen Mandanten gehören, durch böswilligen Code verringert wird.