Stellen Sie Oracle Cloud Infrastructure Kubernetes Engine (OKE) mit erweiterten Terraform-Modulen bereit

Einführung

Dies ist das zweite Tutorial in unserer Automatisierungsserie Oracle Cloud Infrastructure Kubernetes Engine (OKE), das auf den grundlegenden Konzepten des ersten aufbaut, Oracle Cloud Infrastructure Kubernetes Engine-Cluster mit Terraform erstellen. In diesem Artikel bringen wir OKE-Deployments auf die nächste Ebene, indem wir fortgeschrittene Automatisierung und modulares Design für das Provisioning skalierbarer, resilienter und hochgradig anpassbarer Umgebungen auf Oracle Cloud Infrastructure (OCI) einführen.

Dieses Handbuch wurde für Oracle-Ingenieure und -Kunden entwickelt und ermöglicht Ihnen, eine grundlegende Terraform-Konfiguration in ein strukturiertes, wiederverwendbares Modul zu verwandeln, das auf jede Deployment-Größe zugeschnitten werden kann. Durch die Nutzung von Infrastructure-as-Code (IaC)-Prinzipien mit Terraform (Communityversion) in Kombination mit Jenkins und Oracle Command Line Interface (CLI) bieten wir eine single-click-Provisioning-Lösung für OKE-Cluster, deren Konfigurationen und automatisierte Tests.

Dieses Tutorial konzentriert sich auf vier Schlüsselbereiche:

  1. Modulares Design und Automatisierung: Erstellen Sie wiederverwendbare Module für Kernkomponenten wie VCN, OKE-Cluster und Bastionhosts, mit Versionierung für Kompatibilität, um die Verwaltung zu vereinfachen und die Wiederverwendung von Code zu fördern.
  2. Dynamische Konfiguration: Verwalten Sie umgebungsspezifische Einstellungen (Dev, Test, Prod) über eine einzige Codebasis für konsistente und wiederholbare Deployments.
  3. Erweiterte Knotenpools: Optimieren Sie Ressourcennutzung und -kosten mit speziellen Ausprägungen, kompatiblen OKE-Images und Labels für eine intelligente Workload-Platzierung.
  4. Nahtlose CI/CD-Integration: Automatisieren Sie das OKE-Provisioning und -Updates mit Pipelines, die Terraform, Jenkins und OCI-CLI für effiziente one-click-Deployments integrieren.

Die in diesem Handbuch dargestellte Architektur verwendet eine Tiered Network Topology, um eine sichere und skalierbare Grundlage zu schaffen. Es trennt Control Plane, Worker-Knoten und Load-Balancer-Traffic und stellt so Flexibilität für Unternehmens-Workloads jeder Größenordnung sicher. Wir zeigen Ihnen, wie Sie das Provisioning dieser Umgebung, einschließlich Networking, Cluster und Knotenpools, vollständig automatisieren und gleichzeitig die Tools zur Anpassung und Erweiterung der Lösung an Ihre Anforderungen bereitstellen.

In diesem Tutorial werden die Grundlagen von Kubernetes, Networking und IaC sowie Kenntnisse über Tools wie Terraform, OCI CLI und Jenkins vermittelt. Am Ende verfügen Sie über die Fähigkeiten, eine resiliente, leistungsstarke und skalierbare OKE-Umgebung auf OCI bereitzustellen, mit der Flexibilität, sie an Ihre spezifischen Anforderungen anzupassen.

Überblick über Oracle Cloud Infrastructure Kubernetes Engine (OKE)

Auch wenn Oracle Cloud Infrastructure Kubernetes Engine (OKE) ein verwalteter Service ist, erfordert die erfolgreiche Ausführung geschäftskritischer Workloads einen bewussten und gut strukturierten Architekturansatz. Der Übergang von einem Basissetup zu einer skalierbaren Umgebung der Unternehmensklasse erfordert eine sorgfältige Planung und die Verwendung von Infrastructure-as-Code-(IaC-)Tools wie Terraform.

Modularisierung und Automatisierung sind für OKE von entscheidender Bedeutung, um Skalierbarkeit, Sicherheit und betriebliche Effizienz sicherzustellen. Durch die Nutzung strukturierter Module und Automatisierungstools können Unternehmen geschäftskritische Workloads konsistent bereitstellen und verwalten, manuelle Fehler reduzieren und die Markteinführungszeit verkürzen.

Das folgende Diagramm veranschaulicht die OKE-Architektur, wobei die abgestufte Netzwerktopologie, der private API-Endpunkt und sichere Zugriffskontrollen hervorgehoben werden:

OKE Architektur

Ein detailliertes Beispiel für die Architektur finden Sie in der Oracle-Dokumentation.

Überlegungen zur Architektur
Beim Erstellen einer skalierbaren OKE-Umgebung müssen mindestens die folgenden wichtigen technischen Herausforderungen bewältigt werden:

Wichtige Designelemente
Diese modulare Lösung basiert auf einer abgestuften Netzwerkarchitektur und bietet eine sichere und skalierbare Grundlage für Unternehmens-Workloads auf OKE:

Modulare Terraform-Automatisierung für OKE erstellen

Das modulare Design einer flat-Terraform-Konfiguration in eine structured-Konfiguration ist für die Erstellung wiederholbarer und skalierbarer Umgebungen unerlässlich. Dieser Ansatz gewährleistet eine bessere Organisation, Wiederverwendbarkeit von Code und Verwaltbarkeit auf Unternehmensebene mit Versionierung für Kompatibilität und Zusammenarbeit zwischen Teams.

Transformationsprozess: Flaches bis strukturiertes Modul

Ausgehend vom im ersten Tutorial beschriebenen flachen Modul wandeln wir den Code in ein modulares Design um, indem wir:

  1. Verzeichnis neu strukturieren: Untergeordnete Module (vcn, oke, bastion) erstellen und Ressourcen in den jeweiligen Ordnern organisieren.
  2. Anwenden von Schlüsselprinzipien:
    • Struktur und Logik: Kapselt Ressourcen in in eigenständigen Verzeichnissen (z.B. modules/vcn, modules/oke, modules/bastion) und teilt monolithischen Code zur besseren Lesbarkeit und Verwaltbarkeit in main.tf, variables.tf und outputs.tf auf.
    • Eingaben/Ausgaben und Versionierung: Definieren Sie Eingaben in variables.tf, geben Sie Ausgaben in outputs.tf an, und verwenden Sie die Terraform-Modulversionierung (Constraint version in source), um einen nahtlosen Datenfluss und eine nahtlose Kompatibilität zu gewährleisten.
    • Orchestrierung: Behandeln Sie bedingte Logik wie count auf der Root-Modulebene, sodass sich untergeordnete Module auf ihre Ressourcen konzentrieren.

Verzeichnisstruktur: Flat vs. Modular

Flaches Modul: Ein einzelnes, monolithisches Verzeichnis mit allen Ressourcen in einigen Dateien. Einfach für Proofs of Concept, aber mit zunehmender Komplexität unüberschaubar.

Flachmodulstruktur

Strukturiertes Modul: Jede Ressourcengruppe (VCN, OKE, Bastion) befindet sich in ihrem eigenen Modulverzeichnis. Das Root-Modul orchestriert Abhängigkeiten und die Konfiguration der obersten Ebene.

Erweiterte Modulstruktur

Beispielmodule

Warum Module?

Module Orchestrierung - root main.tf

Die Root main.tf orchestriert das Deployment von drei Schlüsselmodulen (modules/vcn, modules/oke und modules/bastion) sequenziert. Jedes Modul wird basierend auf Konfigurations-Flags (is_vcn_created, is_oke_created, is_bastion_created) bedingt aufgerufen, was Flexibilität beim Deployment bietet. Im Folgenden finden Sie eine vereinfachte Version des Orchestrierungsablaufs, in der die Schlüsselmodullogik hervorgehoben wird, ohne die vollständige main.tf anzugeben.

Orchestrierungsablauf:

  1. VCN-Modul (modules/vcn):
    • Stellt das virtuelle Cloud-Netzwerk (VCN) und zugehörige Subnetze bereit (z.B. private Subnetze für Kubernetes-API und Worker-Knoten, öffentliche Subnetze für Load Balancer und Bastion).
    • Kontrolliert durch is_vcn_created. Wenn diese Option aktiviert ist, wird das VCN erstellt. Andernfalls wird ein vorhandenes VCN angenommen (Sie müssen die verwendete Subnetz-OCID angeben).
    • Beispiel-Snippet: 
         module "vcn" {
       count = var.is_vcn_created ? 1 : 0  
       source = "./modules/vcn?ref=v1.0.0"  # Specify the module version  
       # Key variables: compartment_id, vcn_cidr_block, subnet configs, ...  
   }
  2. OKE-Modul (modules/oke):
    • Stellt das OCI Kubernetes Engine-(OKE-)Cluster bereit, einschließlich der Control Plane und optionaler verwalteter Knotenpools.
    • Abhängig vom VCN-Modul für Subnetz-IDs. Wird nur aufgerufen, wenn is_oke_created und is_vcn_created wahr sind.
    • Beispiel-Snippet: 
         module "oke" {
       count = var.is_oke_created && var.is_vcn_created ? 1 : 0  
       source = "./modules/oke?ref=v1.0.0"  # Specify the module version   
       # Key variables: vcn_id, subnet IDs, k8 version, node pool config, ...  
   }
  3. Bastionmodul (modules/bastion):
    • Erstellt einen Bastionhost für sicheren SSH-Zugriff auf private Ressourcen.
    • Hängt vom VCN-Modul für die öffentliche Subnetz-ID ab. Wird nur aufgerufen, wenn is_bastion_created und is_vcn_created wahr sind.
    • Beispiel-Snippet: 
         module "bastion" {
       count = var.is_bastion_created && var.is_vcn_created ? 1 : 0  
       source = "./modules/bastion?ref=v1.0.0"  # Specify the module version   
       # Key variables: bastion_subnet_id, SSH keys, parameters...  
   }

      Wichtige Hinweise:

    • Modulabhängigkeiten: Ausgaben des VCN-Moduls wie module.vcn[0].vcn_id werden als Eingaben an die OKE- und Bastionmodule übergeben, um eine klare Abhängigkeitskette sicherzustellen.
    • Konfigurationslogik: Vereinfachte Parameterzuordnungen (z.B. node_pool_param, bastion_params) optimieren die Konfiguration und Lesbarkeit.
    • Versionierung: Durch die Verwendung von Versions-Constraints in source wird sichergestellt, dass Module mit den richtigen und getesteten Versionen bereitgestellt werden, um die Kompatibilität sicherzustellen

Nach dem Aufbau einer modularen Terraform-Struktur für OKE besteht der nächste Schritt darin, das Deployment zu automatisieren. Die Automatisierung gewährleistet Konsistenz, reduziert manuelle Fehler, beschleunigt den Provisioning-Prozess und verbessert die Time-to-Market (TTM) direkt, indem sie eine schnelle Bereitstellung neuer Features und Services ermöglicht.

Automatisierungsoptionen

Mehrere Tools können OKE-Deployments automatisieren, darunter Terraform-CLI, OCI Resource Manager (ORM), OCI-CLI, Ansible-OCI-Module und Helm. In diesem Handbuch werden jedoch die beiden wichtigsten Infrastructure-as-Code-(IaC-)Ansätze in Oracle Cloud Infrastructure (OCI) behandelt: Terraform-CLI und OCI Resource Manager (ORM).

Beide Tools nutzen dieselbe deklarative HashiCorp Configuration Language (HCL), unterscheiden sich jedoch in ihren Betriebsmodellen:

Lassen Sie uns jede Option im Detail untersuchen.

Option 1: OKE-Ressourcen mit Terraform-CLI bereitstellen

Die Terraform-CLI ist ideal, wenn Sie vollständige Kontrolle über Ihre lokale Umgebung benötigen. Es eignet sich am besten für einzelne Entwickler oder kleine Teams, die die Statusdatei verwalten und effektiv mit einem freigegebenen Backend zusammenarbeiten können. Seine Portabilität ermöglicht es Ihnen, es von jedem Rechner aus auszuführen: lokalen, VM-, Container-, OCI CloudShell- oder CI/CD-Läufern wie Jenkins. Diese Flexibilität umfasst jedoch Verantwortlichkeiten wie die Verwaltung von Statusdateien und die Gewährleistung konsistenter lokaler Setups für alle Teammitglieder.

Laden Sie zunächst das Terraform-CLI-Quellcodepackage in Ihr Terraform-Arbeitsverzeichnis herunter, und dekomprimieren Sie es. Dieses Package umfasst main.tf, ein terraform.tfvars-Beispiel und detaillierte Modulkonfigurationen: Laden Sie oke_advanced_module.zip herunter.

Das Deployment von OKE mit der Terraform-CLI umfasst sieben Hauptaufgaben, von der Konfiguration von Variablen und Netzwerken bis zum Einrichten des OKE-Clusters, der Knotenpools und des Bastionhosts. Im Folgenden finden Sie die detaillierten Schritte zum Provisioning und Prüfen Ihrer OKE-Umgebung mit der Terraform-CLI.

Aufgabe 1.1: Terraform-Variablen konfigurieren

Aktualisieren Sie die Datei terraform.tfvars mit umgebungsspezifischen Details wie tenancy_ocid, Region, compartment_ocid und network_compartment_ocid. Aktivieren Sie die folgenden Flags, um die Ressourcenerstellung zu steuern:

Aufgabe 1.2: Netzwerkkonfiguration

Definieren Sie CIDR-Blöcke für das VCN und die zugehörigen Subnetze:

Aufgabe 1.3: OKE-Clusterkonfiguration

Aufgabe 1.4: Knotenpoolkonfiguration

Aufgabe 1.5 - Bastionhostkonfiguration

Aufgabe 1.6: Terraform-Befehle ausführen

Führen Sie die folgenden Befehle aus, um die Infrastruktur bereitzustellen:

	terraform init
	terraform plan
	terraform apply

Nach Abschluss von terraform apply wird das OKE-Cluster wie folgt bereitgestellt:

Aufgabe 1.7: Verifizierung

  1. Navigieren Sie zur OCI-Konsole, um die Clusterkonfiguration zu prüfen.
  2. Führen Sie terraform destroy aus, um Ressourcen zu bereinigen, wenn Sie fertig sind.

OKE-Deployment mit Jenkins CI/CD-Pipeline automatisieren
Für die Integration des OKE-Deployments in DevOps-Pipelines ist die Terraform-CLI eine hervorragende Wahl. Unser Ansatz, der unter Oracle Cloud Infrastructure Kubernetes Engine-Cluster mit Terraform erstellen beschrieben wird, verwendet bash-Skripting, um den Prozess zu orchestrieren. Dieser Workflow kann zur automatischen Ausführung in eine Jenkins-Pipeline konsolidiert werden.

Option 2: OKE mit OCI Resource Manager automatisieren

OCI Resource Manager (ORM) ist die ideale Wahl, wenn Sie eine verwaltete, Cloud-native Lösung für Infrastrukturbereitstellungen benötigen. Sie eignet sich besonders für kollaborative Unternehmensumgebungen, in denen Sicherheit, zentralisiertes Zustandsmanagement und Governance von entscheidender Bedeutung sind. Der Hauptvorteil von ORM besteht darin, dass es den gesamten Deployment-Lebenszyklus innerhalb von OCI verwaltet, die Statusdatei sicher speichert und Konflikte verhindert. Dadurch entfällt die Notwendigkeit, ein lokales Setup oder ein gemeinsames Backend zu verwalten. Darüber hinaus ermöglicht die tiefe Integration von ORM in die Oracle Cloud die Nutzung von OCI-nativen Features wie Identity and Access Management (IAM), wodurch Sicherheit und Kontrolle verbessert werden.

In diesem Tutorial kombinieren wir OCI Resource Manager (ORM) mit OCI CLI, Bash und integrieren sie in Jenkins CI/CD-Pipelines und bieten einen vollständigen one-click-Automatisierungsfluss mit zusätzlichen DevOps-Funktionen wie Abweichungserkennung, sicheres Zustandsmanagement und Teamzusammenarbeit mit Versionierung zur Kompatibilität.

OCI Resource Manager-Ablauf
Das folgende Diagramm veranschaulicht den ORM-Workflow, der aus sieben Schritten besteht:
ORM-Workflow

  1. Quellkonfiguration: Definiert den Ursprung der IaC-Konfiguration (z.B. OCI Object Storage, GitHub, ZIP-Datei).
  2. Terraform-Vorlage: Die Infrastruktur wird mit Terraform definiert.
  3. OCI Resource Manager: ORM übernimmt die Terraform-Vorlage und verwaltet den Provisioning-Prozess.
  4. Stack erstellen: ORM verwendet die Vorlage, um einen Stack von OCI-Ressourcen zu erstellen.
  5. Planen: Generiert einen Plan, der die auszuführenden Aktionen beschreibt.
  6. Anwenden: Stellt die Ressourcen basierend auf dem Plan bereit.
  7. Löschen: Deprovisioniert die Ressourcen, wenn sie nicht mehr benötigt werden.

Um ein OKE-Cluster mit dem neuen Modul von OCI Resource Manager (ORM) bereitzustellen, laden Sie zunächst das erweiterte Modul für ORM herunter: oke_advanced_module_orm.zip. Diese Version ist für ORM vorkonfiguriert, wobei Variablen auf generische Platzhalter wie REPLACE_WITH_YOUR_OWN_VARIABLE_VALUE gesetzt sind.

Aufgabe 2.1: Quellkonfiguration

Aktualisieren Sie variables.tf mit Ihren umgebungsspezifischen Details, wie Region, Netzwerk-CIDRs und Flags, um die Ressourcenerstellung zu steuern (VCN, OKE-Cluster, Knotenpool, Bastionhost).

Das folgende bash-Skript erstellt die ZIP-Datei der ORM-Ressourcenquellen.

Prüfen Sie das Quellverzeichnis (~/oke_advanced_module_orm), um sicherzustellen, dass eine Datei mit dem Namen stackconfig.zip alle Terraform-Ressourcendefinitionen enthält.

Aufgabe 2.2: OCI Resource Manager-Stack erstellen

Mit der OCI-CLI können Sie einen ORM-Stack erstellen. Das folgende Skript vereinfacht den Prozess:

Bash-Skript: create_new_oke_stack.sh.

	#!/bin/bash
	
	# Load environment variables (e.g., COMPARTMENT_ID, STACK_NAME, etc.)
	source "./env-vars"

	# Create the Oracle Resource Manager stack and capture the OCID
	stack_output=$(oci resource-manager stack create \
	--compartment-id "$COMPARTMENT_ID" --display-name "$STACK_NAME" \
	--description "$STACK_DESCRIPTION" --config-source "$CONFIG_SOURCE")

	# Extract the OCID of the newly created stack and display it
	STACK_OCID=$(echo "$stack_output" | jq -r '.data.id')

	echo "Stack OCID: $STACK_OCID"

Aufgabe 2.3: Stackplanjob ausführen

Führen Sie den Job Plan aus, um die Änderungen zu prüfen, bevor Sie sie anwenden. Dieser Trockenlauf sorgt für Transparenz bei den Infrastrukturänderungen.

Bash-Skript: create_oke_stack_plan_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID)
	source "./env-vars"

	# Create a plan job for the specified stack
	plan_job_output=$(oci resource-manager job create-plan-job \
		--stack-id "$STACK_OCID")

	# Extract the OCID of the plan job and check for errors
	PLAN_JOB_OCID=$(echo "$plan_job_output" | jq -r '.data.id')
	if [[ -z "$PLAN_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve plan job OCID." >&2
		exit 1
	fi

	echo "Plan job OCID: $PLAN_JOB_OCID"

Aufgabe 2.4: Apply-Job erstellen

Stellen Sie das OKE-Cluster und die zugehörigen Ressourcen wie den Knotenpool mit dem Job Apply bereit.

Bash-Skript: create_oke_stack_apply_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID, EXEC_PLAN_STRATEGY)
	source "./env-vars"

	# Create an apply job for the specified stack
	apply_job_output=$(oci resource-manager job create-apply-job \
		--stack-id "$STACK_OCID" \
		--execution-plan-strategy "$EXEC_PLAN_STRATEGY")

	# Extract the OCID of the apply job and check for errors
	APPLY_JOB_OCID=$(echo "$apply_job_output" | jq -r '.data.id')
	if [[ -z "$APPLY_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve apply job OCID." >&2
		exit 1
	fi

	echo "Apply job OCID: $APPLY_JOB_OCID"

Aufgabe 2.5: Zerstörungsjob ausführen

Bereinigen Sie Ressourcen, indem Sie den Job Destroy ausführen, wenn die Umgebung nicht mehr benötigt wird.

Bash-Skript: create_oke_stack_destroy_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID, EXEC_PLAN_STRATEGY)
	source "./env-vars"

	# Create an  jotroy for the specified stack
	apply_job_output=$(oci resource-manager job create-destroy-job \
		--stack-id "$STACK_OCID"  \
		--execution-plan-strategy "$EXEC_PLAN_STRATEGY")

	# Extract the OCID of the destroy job and check for errors
	DESTROY_JOB_OCID=$(echo "$apply_job_output" | jq -r '.data.id')
	if [[ -z "$DESTROY_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve destroy job OCID." >&2
		exit 1
	fi

	echo "Apply job OCID: $DESTROY_JOB_OCID"

OKE mit Jenkins und OCI Resource Manager automatisieren

Wir haben eine Jenkins-Pipeline erstellt, um den End-to-End-Provisioning-Prozess zu automatisieren (Aufgaben 2.1–2.4). Die Pipeline führt bash-Skripte mit der OCI-CLI aus, um mit ORM zu interagieren.

Die folgende Abbildung zeigt die one-click-Automatisierung für die ersten vier Aufgaben. Der Schritt destroy ist aus Gründen der Einfachheit nicht enthalten.

OKEJenkinsPipeline

Die Pipeline umfasst Quellkonfiguration, ORM-Stackerstellung, Plangenerierung, Ressourcen-Provisioning und optionales Ressourcendeprovisioning.

Nächste Schritte:

Durch die Verwendung von Terraform für das OKE-Provisioning wird Konsistenz, Automatisierung und Skalierbarkeit sichergestellt. Modulare Designs in Kombination mit OCI Resource Manager und CI/CD-Pipelines vereinfachen und vereinfachen die Verwaltung der Bereitstellungen. Im nächsten Tutorial werden Best Practices für Überwachung, Sicherheit und Produktionsbereitschaft behandelt. Aufbauend auf diesen Grundlagen werden wir die Module auf Oracle AIOps erweitern, einen End-to-End-OKE-Blueprint für KI-Anwendungen erstellen und demonstrieren, wie Logginganalysen mit KI-gesteuerter Beobachtbarkeit Anomalien erkennen und die Sicherheit der Containerplattform stärken 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.