Oracle Kubernetes Engine (OKE) für die Produktion bereitstellen: Best Practices und Richtlinien

Einführung

Dies ist das dritte Tutorial in unserer Automatisierungsreihe Oracle Cloud Infrastructure Kubernetes Engine (OKE), das auf den Konzepten basiert, die im zweiten Tutorial vorgestellt wurden: Bereitstellen von Oracle Cloud Infrastructure Kubernetes Engine (OKE) mit erweiterten Terraform-Modulen. In diesem Handbuch konzentrieren wir uns auf produktionsbereite OKE-Bereitstellungen und lernen wichtige Best Practices kennen, mit denen die Clusterzuverlässigkeit verbessert, Kosten optimiert und Abläufe vereinfacht werden. Wir zeigen einige der Best Practices, die Terraform verwenden, und heben gleichzeitig häufige Fallstricke hervor, die Benutzern beim Erstellen von Clustern begegnen.

Gründe für das Deployment von OKE in einem vorhandenen VCN

Für die Erstellung eines produktionsgerechten OKE-Clusters ist eine sorgfältige Planung über Netzwerk-, Knotenplatzierungs- und Betriebsprozesse hinweg erforderlich. Durch das Deployment in einem vorhandenen virtuellen Cloud-Netzwerk (VCN) kann Ihr Cluster nahtlos in vorkonfigurierte Subnetze, Routentabellen und Sicherheitsregeln integriert werden. Dadurch wird der Betriebsaufwand reduziert, die Konsistenz mit der Infrastruktur Ihres Unternehmens sichergestellt und mehrere Workloads oder Cluster können effizient im selben Netzwerk zusammenleben.

Zu den wichtigsten Terraform-Parametern beim Deployment in einem vorhandenen VCN gehören:

Alternativ können Sie beim Deployment einer brandneuen Umgebung von Grund auf is_vcn_created = true festlegen, um ein neues Netzwerk bereitzustellen. Nach einer erfolgreichen terraform apply erfasst Terraform die OCIDs des neu erstellten VCN und der zugehörigen Subnetze in den Ausgaben. Diese Werte können in zukünftigen Deployments wiederverwendet werden, indem is_vcn_created = false festgelegt und die gespeicherten OCIDs in der Datei terraform.tfvars referenziert werden. Dadurch kann Terraform das vorhandene Netzwerk verwenden, anstatt ein neues zu erstellen. Wenn Sie terraform plan in dieser Phase ausführen, wird bestätigt, dass das aktuelle VCN und die Subnetze beibehalten werden, sodass nicht unnötige Infrastrukturänderungen vermieden werden.

Mit der vorhandenen Netzwerkgrundlage verlagert dieses Tutorial den Fokus auf eine Reihe produktionsorientierter Best Practices, mit denen OKE-Cluster resilienter, skalierbarer und einfacher zu bedienen sind. Durch die Anwendung dieser Praktiken können Kunden OKE-Cluster bereitstellen, die hochverfügbar, kosteneffizient und auf Organisationsrichtlinien, Governance-Standards und produktionsreife Betriebsanforderungen abgestimmt sind. Laden Sie den neuesten Code von hier oke_advanced_module.zip herunter.

OKE Best Practices: Richtlinien zur Produktionsbereitschaft

1. Verwenden Sie Knotenneustart, um OKE-Knotenpools upzugraden.

Node Cycling ist eine sichere, rollierende Upgrade-Strategie, die Knotenimages, Kubernetes-Versionen oder Systemkonfigurationen aktualisiert, ohne Workloads zu unterbrechen. Knotenzyklen sind wichtig, da sie es Clustern ermöglichen, sich im Laufe der Zeit sicher zu entwickeln und Patches oder Upgrades einzuspielen, ohne die Produktions-Workloads zu beeinträchtigen. Für Kunden reduziert dies das Betriebsrisiko, stellt die kontinuierliche Verfügbarkeit bei Upgrades sicher und ermöglicht eine zuverlässige Ausführung von Workloads unter Beibehaltung der neuesten Versionen. OKE unterstützt zwei Typen:

Parameter wie maximum_surge und maximum_unavailable steuern, wie Upgrades Geschwindigkeit und Verfügbarkeit in Einklang bringen. Setzen Sie bei Upgrades ohne Ausfallzeiten maximum_surge = 1 und maximum_unavailable = 0, um sicherzustellen, dass ein neuer Knoten online ist, bevor Sie den alten ersetzen. Das folgende Beispiel zeigt ein Beispiel für einen Knotenwechsel mit "Max. Anstieg 1" und "Max. nicht verfügbar 0".

OKENodepoolupgraded

So lösen Sie das Upgrade eines vorhandenen OKE-Clusters aus, das zum erneuten Hochfahren von Knoten führt:

In der Datei terraform.tfvars:

Führen Sie dann terraform plan aus.

Die Ausgabe sollte wie folgt angezeigt werden:

Wenn Sie terraform apply ausführen, beginnt OKE mit dem Neustart der Knotenpools einen Knoten nach dem anderen mit der Strategie BOOT_VOLUME_REPLACE. In diesem Modus wird nur das Boot-Volume des Knotens ersetzt, während die zugrunde liegende Compute-Instanz unverändert bleibt. Infolgedessen wird das Knotenupgrade durchgeführt, und Netzwerkattribute wie die private IP-Adresse bleiben unverändert wie folgt:

OKEclusterUpgrading OKEclusterUpgrading OKEclusterUpgrading

Um Knoten mit der Option INSTANCE_REPLACE neu zu starten, setzen Sie cycle_modes auf INSTANCE_REPLACE, damit OKE die Knotenpools jeweils um einen Knoten neu starten kann. In diesem Modus wird jeder Knoten von Grund auf gelöscht und neu erstellt, einschließlich der Compute-Instanz und des Boot-Volumes. Infolgedessen wendet das Knotenupgrade alle aktualisierten Attribute an, z.B. eine neue Kubernetes-Version oder Ausprägungsänderungen. Netzwerkattribute wie die private IP können sich jedoch ändern. Dieser Ansatz stellt einen vollständig aktualisierten Knoten mit den neuesten Konfigurationen sicher und bietet maximale Update-Abdeckung bei gleichzeitiger Aufrechterhaltung der Clusterverfügbarkeit durch rollierende Ersetzungen, wie unten dargestellt:

OKEclusterUpgrading OKEclusterUpgrading

2. Verwenden Sie OCI-Tagging auf OKE-Worker-Knoten und Load Balancern, um Kosten zu verfolgen

Bei der Ausführung von Kubernetes-Workloads in Oracle Cloud Infrastructure (OCI) müssen Sie unbedingt wissen, woher Ihre Kosten kommen. Tagging ist der Schlüssel. Mit OCI können Sie definierte Tags und Freiformtags auf jede Ressource anwenden, einschließlich OKE-Clustern, Worker-Knoten, Load Balancern und persistenten Volumes. Dies ist wichtig, da es ein detailliertes Kostenreporting, ein einfacheres Auditing und die Verantwortung für die Cloud-Nutzung ermöglicht. Für Kunden bietet das Tagging Einblicke, welche Workloads die meisten Ressourcen verbrauchen, verbessert die Kostentransparenz und unterstützt Optimierungsentscheidungen zur Kontrolle der Cloud-Ausgaben.

Warum das Tagging wichtig ist:

# Cluster-level tagging
cluster_freeform_tag_key   = "Environment"
cluster_freeform_tag_value = "Development"

# Node pool-level tagging
node_pool_freeform_tag_key   = "LOB"
node_pool_freeform_tag_value = "DevOps Tech"

# Bastion host tagging
freeform_tags = {
  project     = "devops"
  environment = "production"}

# Defined tagging
defined_tags = { 
  “Corporate_Standard.CostCenter”  = “Finance-123"
  “Corporate_Standard.Environment” = “Production” }

Mit diesen Tags können Sie detaillierte Kostenberichte in der OCI-Kostenanalyse generieren, identifizieren, welche Workloads die meisten Ressourcen verbrauchen, und fundierte Entscheidungen über Skalierung oder Optimierung treffen.

3. Separate API-Endpunkt-, Knoten-, Load Balancer- und Podsubnetze (falls zutreffend).

Das richtige Netzwerkdesign ist eine Best Practice in OKE, da es die Sicherheit, Performance und Skalierbarkeit verbessert. Durch die Trennung von API-Endpunkten, Worker-Knoten, Pods, Load Balancern und Bastionhosts in separaten Subnetzen wird kritischer Traffic isoliert, benutzerdefinierte Routentabellen oder Netzwerksicherheitsgruppen (NSGs) ermöglicht und verhindert, dass ein Traffictyp mit einem anderen interferiert. Dieser Ansatz ist unerlässlich, um eine sichere Kommunikation, vorhersehbares Routing und eine starke Ressourcenisolation in Produktionsumgebungen aufrechtzuerhalten.

Kunden profitieren von einem sichereren, verwaltbaren und resilienten Cluster, das effizient skalieren und Trafficspitzen oder -angriffe bewältigen kann, ohne Workloads zu beeinträchtigen. Im Folgenden finden Sie das Snippet aus terrform.tfvars, mit dem Sie CIDR-Blöcke für Subnetze definieren können.

k8apiendpoint_private_subnet_cidr_block       = "REPLACE_WITH_YOUR_CIDR"   # API endpoint subnet
workernodes_private_subnet_cidr_block         = "REPLACE_WITH_YOUR_CIDR"   # Worker nodes subnet
pods_private_subnet_cidr_block                = "REPLACE_WITH_YOUR_CIDR"   # Pod subnet (CNI)
serviceloadbalancers_public_subnet_cidr_block = "REPLACE_WITH_YOUR_CIDR"   # Load balancer subnet
bastion_public_subnet_cidr_block              = "REPLACE_WITH_YOUR_CIDR"   # Bastion host subnet

Durch die Befolgung dieser Übung verbessern Sie die Sicherheit, vereinfachen die Netzwerkverwaltung und machen Ihr Cluster resilienter für Datenverkehrsspitzen oder -angriffe.

4. Knotenpool pro Availability-Domain-Architektur bei Verwendung von Cluster Autoscaler verwenden

In OCI verfügt jede Availability-Domain (AD) über unabhängige Kapazität. Während Knotenpools mehrere ADs umfassen können, um die High Availability zu verbessern, wird dies nicht empfohlen, wenn der Cluster-Autoscaler aktiviert ist. Der Autoscaler benötigt Kapazität in allen ausgewählten ADs und kann möglicherweise nicht skaliert werden, wenn keine AD über Ressourcen verfügt.

Um dies zu vermeiden, müssen Knotenpools so konfiguriert werden, dass sie eine einzelne AD verwenden, wenn Autoscaling aktiviert ist. Wenn die Kapazität in einer AD nicht verfügbar ist, kann der Autoscaler einen alternativen Knotenpool in einer anderen AD skalieren.

Beispielkonfiguration des Knotenpools:

availability_domains = [
      "REPLACE_WITH_YOUR_AD"
    ]

Beispielkonfiguration für Cluster-Autoscaler:

cluster_autoscaler_config = {
  node_mapping = {
    key = "nodes"
    value = "1:5:ocid1.nodepool....."
  }
}

5. Separate Knotenpools für unterschiedliche Workload-Anforderungen (x86, ARM, GPU)

Verwenden Sie separate Knotenpools für Workloads, die verschiedene Compute-Ausprägungen erfordern, wie x86, ARM oder GPU. Dieser Ansatz verbessert die Ressourcennutzung, die Terminierungseffizienz und das Verhalten bei der automatischen Skalierung, indem sichergestellt wird, dass jede Workload auf der am besten geeigneten Infrastruktur ausgeführt wird.

Pods werden mit Knotenlabels, Selektoren, Affinitäten oder Taints und Toleranzen für die richtigen Knotenpools geplant, sodass Kubernetes Workloads mit der erforderlichen Architektur oder den erforderlichen Funktionen auf Knoten platzieren kann.

Durch die Kombination dedizierter Knotenpools mit expliziter Podplatzierung erzielen Kunden eine vorhersehbare Performance, eine effiziente Skalierung und ein vereinfachtes Clustermanagement. In diesem Beispiel werden separate Knotenpools für Intel- und AMD-Ausprägungen erstellt, um eine optimale Workload-Platzierung und belastbare Clustervorgänge sicherzustellen.

worker_node_pools = {
  AMD_node_pool = {
    name               = "node_pool_one"                # Node pool name
    shape              = "VM.Standard.E5.Flex"          # Compute shape
    shape_config = {
      memory = 16                                       # Memory (GB)
      ocpus  = 1                                        # OCPUs
    }
    boot_volume_size   = 50                             # Boot volume size (GB)
    operating_system   = "Oracle-Linux"                 # OS for worker nodes
    kubernetes_version = "v1.33"                        # Node Kubernetes version
    source_type        = "IMAGE"                        # Source type for image
    node_labels = {
      Trigger = "Nodes_Cycling_0"                       # Node label
    }
    availability_domains = [                            # Availability_domain setting
      "REPLACE_WITH_YOUR_AD"
    ]                                                   # ADs for node distribution
    number_of_nodes          = 1                        # Number of worker nodes
    pv_in_transit_encryption = false                    # Boot volume in-transit encryption
    node_cycle_config = {
      node_cycling_enabled = true                       # Enable node cycling by default
      maximum_surge        = 1                          # Number of surge nodes
      maximum_unavailable  = 0                          # Max unavailable nodes
      cycle_modes          = ["BOOT_VOLUME_REPLACE"]    # cycle_modes"BOOT_VOLUME_REPLACE" or "INSTANCE_REPLACE"

    }
    ssh_key = "REPLACE_WITH_YOUR_KEY"                   # SSH public key for workers nodes
  }
  Intel_node_pool = {
    name               = "node_pool_two"                # Node pool name
    shape              = "VM.Standard2.8"      	        # Compute shape
    shape_config = {
      memory = 120                                      # Memory (GB)
      ocpus  = 8                                        # OCPUs
    }
    boot_volume_size   = 50                             # Boot volume size (GB)
    operating_system   = "Oracle-Linux"                 # OS for worker nodes
    kubernetes_version = "v1.33"                        # Node Kubernetes version
    source_type        = "IMAGE"                        # Source type for image
    node_labels = {
      Trigger = "Nodes_Cycling_0"                       # Node label
    }
    availability_domains = [                            # Availability_domain setting
      "REPLACE_WITH_YOUR_AD"  
    ]                                                   # ADs for node distribution
    number_of_nodes          = 1                        # Number of worker nodes
    pv_in_transit_encryption = false                    # Boot volume in-transit encryption
    node_cycle_config = {
      node_cycling_enabled = true                       # Enable node cycling by default
      maximum_surge        = 1                          # Number of surge nodes
      maximum_unavailable  = 0                          # Max unavailable nodes
      cycle_modes          = ["BOOT_VOLUME_REPLACE"]    # cycle_modes"BOOT_VOLUME_REPLACE" or "INSTANCE_REPLACE"

    }
    ssh_key = "REPLACE_WITH_YOUR_KEY"                   # SSH public key for workers nodes
  }

}

Nachdem Sie terraform apply ausgeführt haben, zeigt das OKE-Cluster zwei separate Knotenpools an:

OKEtwonodepools OKEIntelnodepool OKEAMDnodepool

6. Cloud-Init für Knotenanpassung verwenden

Cloud-Init-Skripte sind unerlässlich, um die Worker-Knotenkonfiguration in OKE zu automatisieren und ein konsistentes BS-Setup, Packageinstallation und Systemoptimierung auf allen Knoten sicherzustellen. Durch die Integration von cloud-init in Terraform können Sie Knoten automatisch beim Booten bereitstellen, sodass Bereitstellungen wiederholbar, auditierbar und produktionsreif sind. Weitere Informationen zu cloud-init-Skripten finden Sie in diesem Dokument Benutzerdefinierte Cloud-init-Initialisierungsskripte zum Einrichten verwalteter Knoten verwenden.

Im angegebenen Terraform-Code referenziert jeder Knotenpool ein Cloud-Init-Skript mit dem Parameter cloud_init_path. Kunden können den Inhalt von cloud-init-general.sh entsprechend ihren Anforderungen gemäß den Anweisungen im obigen Dokument ändern. In dieser Demo verwenden wir das standardmäßige Startskript, das in der referenzierten Dokumentation bereitgestellt wird. Kunden können auch den Speicherort des Cloud-Init-Skripts ändern, indem sie den Parameter cloud_init_path aktualisieren, wie unten dargestellt:

cloud_init_path = "cloud-init-general.sh"

Dadurch wird sichergestellt, dass jeder neue oder ersetzte Knoten während des Knoten-Provisionings oder -Neustarts konsistent mit der erforderlichen Systemkonfiguration initialisiert wird. In Kombination mit Terraform ermöglicht cloud-init, dass versionsgesteuerte Skripte automatisch angewendet werden, sodass manuelle Aufgaben nach dem Provisioning entfallen.

Hauptvorteile für Worker-Knoten:

7. OKE-Funktionalität mit Add-ons verbessern

OKE-Add-ons erweitern die Clusterfunktionen für Beobachtbarkeit, Skalierung, Sicherheit und Verkehrsmanagement. Mit Terraform können Sie Add-ons basierend auf Workload-Anforderungen selektiv aktivieren oder deaktivieren und die Ressourcennutzung minimieren:

kubernetes_dashboard_enabled       = false
metrics_server_enabled             = false
cluster_autoscaler_enabled         = false
certificate_manager_enabled        = false
istio_enabled                      = false
native_ingress_controller_enabled  = false

Häufige Add-ons und ihre Vorteile:

Best Practices für Add-ons:

8. Verwenden Sie die OIDC-Authentifizierung/-Discovery, wenn externe Ressourcen Zugriff auf k8s-Cluster benötigen.

Integrieren Sie die OIDC-Discovery mit externen Identitätsprovidern (wie Okta oder Azure AD), wenn Entwickler oder Automatisierungstools außerhalb von OCI sich bei Ihrem Kubernetes-Cluster authentifizieren müssen. Dies ermöglicht ein zentralisiertes Identitätsmanagement und föderierten Zugriff, ohne dass lokale Kubernetes-Benutzer verwaltet oder kubeconfig-Dateien verteilt werden müssen. Dieser Ansatz ist besonders nützlich, wenn externe CI/CD-Tools wie GitHub Actions Zugriff auf das Cluster benötigen oder wenn Workloads im Cluster sicher in externe Services wie HashiCorp Vault integriert werden müssen. Durch die Verwendung von OIDC können Unternehmen konsistente Authentifizierungs-Policys durchsetzen, die Zugriffsverwaltung vereinfachen und den Betriebsaufwand für die Rotation von Zugangsdaten reduzieren, während starke Sicherheitsgrenzen beibehalten werden.

9. Netzwerksicherheitsgruppen anstelle von Sicherheitslisten verwenden

Netzwerksicherheitsgruppen (NSGs) werden beim Sichern von OKE-Clustern gegenüber herkömmlichen Sicherheitslisten bevorzugt. NSGs ermöglichen detailliertere, flexiblere und wiederverwendbare Sicherheitsregeln, die direkt an bestimmte Ressourcen wie Worker-Knoten, Load Balancer oder Pods angehängt werden können. Dadurch eignen sie sich besser für dynamische Kubernetes-Umgebungen, in denen Ressourcen häufig skaliert oder geändert werden. Im Gegensatz dazu gelten Sicherheitslisten auf Subnetzebene und sind so konzipiert, dass sie ganze VCNs oder Subnetze umfassen, was bei der Implementierung fein granulierter Anwendungssicherheitsanforderungen weniger Kontrolle bietet. Die Verwendung von NSGs verbessert die Sicherheitshygiene, vereinfacht das Regelmanagement und ermöglicht eine engere Isolierung zwischen Clusterkomponenten.

10. Beobachtbarkeit mit OCI Logging Analytics und OKE-Metriken aktivieren

Integrieren Sie OKE in OCI Logging Analytics und Monitoring, um einen tiefen Einblick in die Cluster- und Workload-Performance zu erhalten. Logging Analytics bietet erweiterte Logaggregation, Parsing und Anomalieerkennung, während Monitoring Metriken aus der Kubernetes-Control-Plane und den Worker-Knoten erfasst. Zusammen ermöglichen diese Services es Teams, Trends zu visualisieren, Probleme schneller zu beheben und Alerts für ein proaktives Management zu konfigurieren. Diese Lösung eignet sich besonders für Kunden, die eine OCI-native Beobachtbarkeitsplattform suchen, die die Komplexität der Logaufnahme, -speicherung und -analyse abstrahiert und gleichzeitig nahtlos in andere OCI-Services integriert.

11. Verwenden Sie die Workload-Identität, wenn Pods Zugriff auf OCI-Ressourcen benötigen.

Bei der Authentifizierung bei OCI werden häufig API-Schlüssel verwendet. Diese Zugangsdaten sind jedoch langlebig und erfordern einen persistenten Speicher, sodass sie nur schwer sicher in großem Maßstab verwaltet werden können. Während Instanz- und Ressourcen-Principals dies verbessern, indem Compute-Instanzen oder Services ihre eigene Identität annehmen können, erweitert OKE Workload Identity dieses Konzept weiter, indem einzelne Kubernetes-Pods ihre eigene OCI-Identität annehmen können. Durch die Aktivierung von OCI Workload Identity können Pods sicher auf OCI-Services wie Object Storage oder Logging mit IAM-Policys zugreifen, ohne Hardcoding-Zugangsdaten oder auf Berechtigungen auf Knotenebene angewiesen zu sein. Dies bietet eine feingranulierte, auditierbare und sichere Zugriffskontrolle, die für Kubernetes-Umgebungen der Produktionsklasse mit mehreren Mandanten unerlässlich ist.

12. Verwenden Sie die entsprechende Subnetzgröße für OKE-Knoten und -Pods.

Die korrekte Planung von Subnetz-CIDR-Blöcken ist eine Best Practice, da für jeden Knoten eine primäre IP und zusätzliche sekundäre IPs für Pods erforderlich sind. Kleine Subnetze können schnell zu IP-Erschöpfung führen und Skalierungen oder Upgrades verhindern. Dies ist wichtig, um die Clusterstabilität zu erhalten und das Wachstum zu unterstützen. Kunden profitieren davon, indem sie sicherstellen, dass Cluster vorhersehbar skaliert werden können, Betriebsunterbrechungen vermeiden und zukünftige Workloads unterstützen können, ohne dass ein Neugestaltung des Netzwerks erforderlich ist. Weisen Sie in Produktionsumgebungen größere CIDR-Blöcke zu, und lesen Sie die OKE-Dokumentation zur Subnetzgrößenermittlung, um sicherzustellen, dass Ihr VCN aktuelle und zukünftige Workload-Anforderungen unterstützen kann.

13. Full Stack Disaster Recovery-Service zum Backup des k8s-Clusters verwenden

Die Nutzung des OCI Full Stack Disaster Recovery für das OKE-Cluster ist eine Best Practice, da es die Clusterkonfiguration, die Anwendungen und das Networking durch koordiniertes Failover und Failback regionsübergreifend schützt. Dies ist wichtig für die Geschäftskontinuität und Compliance bei regionalen Ausfällen oder Systemausfällen. Kunden profitieren von kürzeren Ausfallzeiten, schneller Wiederherstellung und der Gewissheit, dass geschäftskritische Workloads auch bei Katastrophen betriebsbereit bleiben.

Weitere Informationen finden Sie unter Switchover- und Failover-Pläne für OCI Kubernetes Engine (Zustandsbehaftet) mit OCI Full Stack Disaster Recovery automatisieren

Nächste Schritte:

Mit Terraform wird das OKE-Provisioning konsistent, automatisiert und skalierbar. Durch die Befolgung von Best Practices wie OCI-Tagging, Subnetztrennung und standardisierte Knotenkonfiguration bleiben Ihre Cluster sicher, organisiert und kostentransparent. Im nächsten Blog werden wir auf diesen Grundlagen aufbauen, um KI-gesteuerte Vorgänge zu untersuchen und zu zeigen, wie Oracle AIOps integriert, KI-gestützte Beobachtbarkeit ermöglicht und ein End-to-End-OKE-Blueprint für KI-Workloads erstellt wird. Bleiben Sie auf dem Laufenden für unsere bevorstehende LiveLabs-Session, in der Sie praktische Erfahrungen mit diesen Techniken sammeln und mit OKE-Deployments in einer Liveumgebung experimentieren können.

Bestätigungen

Weitere Lernressourcen

Sehen Sie sich weitere Übungen zu docs.oracle.com/learn an, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning YouTube-Kanal zu. Besuchen Sie außerdem education.oracle.com/learning-explorer, um ein Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.