Einheit 3.2: Kubernetes-Bereitstellung und -Betrieb

Einführung

Sie haben die Container-Anwendungen von TaskBoards API, Frontend und Worker in Einheit 3.1 containerisiert und sie mit git-SHA-Tags zu Private Container Registry gepusht. Jetzt benötigen Sie einen Ort, um sie auszuführen. In dieser Einheit bereiten Sie eine Managed Kubernetes (MKS) Cluster als Code vor, verbinden die Registrierungsinformationen mit der Cluster, damit sie Ihre Bilder abrufen kann, und deployen alle drei Dienste als Standard-Kubernetes-Ressourcen.

Die MKS-Steuerungsebene wird für Sie gemanagt, aber zwei IONOS-spezifische Realitäten prägen jede Bereitstellung, die Sie schreiben. Erstens bereit eine Service vom Typ LoadBalancer auf MKS keine externe Load Balancer, so dass der Produktions-Eingang von einem separat bereitgestellten Application Load Balancer (ALB) vorgerüstet wird. Zweitens sind die Steuerungsereignisse, die Sie in einem zentralen Log-Stream erwarten, nicht vorhanden, was ändert, wie Sie debuggen. Sie werden Code für beide Realitäten schreiben, anstatt darum herumzuarbeiten, wenn sie Sie in der Produktion beißen.

1. Bereitstellung des Cluster mit Terraform

Ein Managed Kubernetes Cluster bei IONOS besteht aus zwei unterschiedlichen Ressourcen: dem Cluster (der gemanagten Steuerungsebene) und einer oder mehreren Node Pools (den Arbeits-Computern, für die Sie bezahlen). Die Steuerungsebene selbst ist kostenlos; Sie zahlen nur für die zugrunde liegenden Node-Pool-Computer und die Block Storage-Volumen, die Ihre Pods bereitstellt. Erstellen Sie zunächst den Cluster und fügen Sie dann Node Pools hinzu, die darauf verweisen.

1.1 Cluster- und Node-Pool-Ressourcen

Die ionoscloud_k8s_cluster-Ressource definiert die Steuerungsebene und ihre Kubernetes-Version. Die ionoscloud_k8s_node_pool-Ressource definiert Worker Nodes innerhalb eines bestimmten Rechenzentrums.

resource "ionoscloud_k8s_cluster" "taskboard" {
  name        = "taskboard-prod"
  k8s_version = "1.34"

  maintenance_window {
    day_of_the_week = "Sunday"
    time            = "03:00:00Z"
  }
}

resource "ionoscloud_k8s_node_pool" "app" {
  name              = "taskboard-app-pool"
  k8s_cluster_id    = ionoscloud_k8s_cluster.taskboard.id
  datacenter_id     = ionoscloud_datacenter.taskboard.id
  k8s_version       = ionoscloud_k8s_cluster.taskboard.k8s_version
  cpu_family        = "INTEL_SKYLAKE"
  server_type       = "DedicatedCore"
  node_count        = 3
  cores_count       = 4
  ram_size          = 8192
  availability_zone = "AUTO"
  storage_type      = "SSD"
  storage_size      = 100
}

Unterstützte Kubernetes-Versionen sind 1.34, 1.33, 1.32 und 1.31. Verwenden Sie eine explizite k8s_version-Version, anstatt die neueste Version zu verfolgen, da jedes Node-Pool-Upgrade während des Wartungsfensters durchgeführt wird und zu Verbindungsabbrüchen führen kann. Node Pools akzeptieren sowohl DedicatedCore- als auch vCPU-Server-Typen, sodass Sie die Größe des App-Pools von TaskBoard auf Dedicated Core für eine vorhersehbare Leistung festlegen können.

1.2 Abrufen der kubeconfig aus dem Zustand

Sie laden die kubeconfig nicht aus einer Benutzeroberfläche herunter. Die Cluster-Ressource stellt die Konfiguration direkt bereit, sodass Terraform sie auf die Festplatte schreiben kann, um sie für kubectl und CI zu verwenden.

output "kubeconfig" {
  value     = ionoscloud_k8s_cluster.taskboard.kube_config
  sensitive = true
}

resource "local_file" "kubeconfig" {
  content         = ionoscloud_k8s_cluster.taskboard.kube_config
  filename        = "${path.module}/kubeconfig.yaml"
  file_permission = "0600"
}

export KUBECONFIG=$(pwd)/kubeconfig.yaml
kubectl get nodes

Die kubeconfig kann auch über die API unter GET /k8s/{k8sClusterId}/kubeconfig und über ionosctl k8s kubeconfig get --cluster-id <id> abgerufen werden. Behandeln Sie sie als Geheimnis: Sie gewährt den vollen Zugriff auf den Cluster. Markieren Sie die Terraform-Ausgabe als sensitive und committen Sie die generierte Datei nie.

2. Bereitstellung von Workloads in MKS

Sobald kubectl das Cluster erreicht, verhält sich MKS wie ein Standard-Kubernetes. Es gibt keinen IONOS-spezifischen Manifest-Dialekt. Sie wenden Deployments, Services, ConfigMaps und Secrets genau so an, wie Sie es bei jedem konformen Cluster tun würden. Das CNI ist Calico und festgelegt, sodass die Netzwerkpolicie-Erstellung Calico-Semantik folgt, ohne die Möglichkeit, das Plugin auszutauschen.

2.1 Bereitstellung, ConfigMap und Secret

TaskBoards API benötigt nicht-geheime Konfigurationen und geheime Anmeldeinformationen. Trennen Sie sie: Ein ConfigMap für den Datenbank-Host und Funktionsflags, ein Secret für das Verbindungspasswort.

apiVersion: v1
kind: ConfigMap
metadata:
  name: taskboard-config
  namespace: taskboard
data:
  DB_HOST: "pg-cluster.taskboard.internal"
  CACHE_TTL: "300"
---
apiVersion: v1
kind: Secret
metadata:
  name: taskboard-db
  namespace: taskboard
type: Opaque
stringData:
  DB_PASSWORD: "REPLACED_FROM_TERRAFORM_OUTPUT"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: taskboard-api
  namespace: taskboard
spec:
  replicas: 3
  selector:
    matchLabels:
      app: taskboard-api
  template:
    metadata:
      labels:
        app: taskboard-api
    spec:
      imagePullSecrets:
        - name: registry-cred
      containers:
        - name: api
          image: <registry-name>.cr.de-fra.ionos.com/taskboard-api:<git-sha>
          ports:
            - containerPort: 8080
          envFrom:
            - configMapRef:
                name: taskboard-config
          env:
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: taskboard-db
                  key: DB_PASSWORD
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 15

Geheime Daten sind in REST in MKS verschlüsselt, aber Kubernetes-Secrets sind nur base64-codiert im Manifest, sodass Sie die Quellwerte immer noch aus Git heraushalten und sie bei der Bereitstellung aus Terraform-Ausgaben injizieren sollten. Der Readiness-Test ist wichtig, da rollierende Updates auf ihn warten, bevor sie den Datenverkehr umleiten.

2.2 Abrufen von Images mit imagePullSecrets

Private Container Registry erfordert eine Authentifizierung für jeden Abruf und es ist ein token-basiertes Docker-Login, nur mit keinem RBAC und keinen team-spezifischen Repositorys. Kubernetes benötigt ein dockerconfigjson-Secret, das aus einem Registrierungstoken erstellt wird, das im Pod-Spezifikation oben als imagePullSecrets referenziert wird.

kubectl create namespace taskboard

kubectl create secret docker-registry registry-cred \
  --namespace taskboard \
  --docker-server=<registry-name>.cr.de-fra.ionos.com \
  --docker-username=<token-name> \
  --docker-password=<registry-token>

Wenn Sie den imagePullSecrets-Verweis auslassen oder das Secret auf den falschen Namespace beschränken, Pods-Stall in ImagePullBackOff. Das Secret ist namespaced, sodass Sie es in jedem Namespace erstellen sollten, der Registrierungs-Images ausführt. In CI erzeugen Sie das Registrierungstoken einmal und speichern es als Pipeline-Geheimnis, dann erstellen Sie das Kubernetes-Secret als Bereitstellungsschritt.

3. Exposing Traffic: die LoadBalancer-Realität

Dies ist die wichtigste IONOS-spezifische Tatsache in der Einheit. Ein Service vom Typ LoadBalancer auf MKS bereitstellt keinen externen Load Balancer. IONOS Cloud reserviert eine statische öffentliche IP und weist sie als sekundäre IP einem Worker-Node zu, das zum Eingangs-Node wird, und kube-proxy leitet den Datenverkehr dann zum Ziel-Pod um.

3.1 Was dies für Ihre Manifeste bedeutet

Zwei Konsequenzen ergeben sich direkt daraus. Die Client-Quell-IP geht verloren, es sei denn, Sie setzen externalTrafficPolicy: Local, und die Durchsatzleistung ist auf die öffentliche Obergrenze von 2 Gbit/s des einzelnen Eingangs-Node begrenzt, da der gesamte Datenverkehr durch einen Node geleitet wird. Es gibt keine automatische Hochverfügbarkeit über Knoten für diese IP.

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
  namespace: ingress
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  selector:
    app: ingress-nginx
  ports:
    - port: 443
      targetPort: 8443

Um den Datenverkehr über einen einzelnen Node hinaus zu skalieren, reservieren Sie mehrere LB-IP-Adressen und verteilen Sie sie über mehrere Eingangsknoten mithilfe von DNS-Lastverteilung. Da nur öffentliche Node Pools den LoadBalancer-Servicetyp überhaupt unterstützen (private Node Pools nicht), halten Sie Ihren internetfähigen Eingangscontroller in einem öffentlichen Pool. Exponieren Sie nur den Eingangscontroller als LoadBalancer, niemals einen Service pro Anwendung.

3.2 Fronting des Cluster mit einem separat bereitgestellten ALB

Für die Produktions-TaskBoard bereitstellen Sie eine Application-Load Balancer separat über Terraform. Der ALB wird nicht automatisch aus einem Kubernetes-Manifest erstellt, sodass es keine Eingangscontroller-Anmerkung gibt, die einen aufruft. Sie stellen ihn als Infrastruktur bereit und zeigen seine Weiterleitungsregeln auf die Node-IPs, die den Eingangscontroller bedienen.

resource "ionoscloud_application_loadbalancer" "taskboard" {
  name          = "taskboard-alb"
  datacenter_id = ionoscloud_datacenter.taskboard.id
  listener_lan  = ionoscloud_lan.public.id
  ips           = [ionoscloud_ipblock.alb.ips[0]]
  target_lan    = ionoscloud_lan.app.id
}

resource "ionoscloud_application_loadbalancer_forwardingrule" "https" {
  datacenter_id               = ionoscloud_datacenter.taskboard.id
  application_loadbalancer_id = ionoscloud_application_loadbalancer.taskboard.id
  name                        = "https-rule"
  protocol                    = "HTTP"
  listener_ip                 = ionoscloud_ipblock.alb.ips[0]
  listener_port               = 443
}

Beachten Sie, dass NSG-Regeln nicht auf den ALB angewendet werden. Network Security Groups binden auf der Server-NIC-Ebene, nicht an den gemanagten ALB oder an MKS, sodass Sie den Eingangsdatenverkehr durch ALB-Weiterleitungsregeln und die Sicherheitsregeln auf den Worker-Node-NICs steuern, nicht indem Sie eine NSG an die Load Balancer anhängen.

4. Node-Pool-Operationen

Node Pools sind die Betriebsfläche, die Sie über die Lebensdauer des Cluster hinweg verwalten: Skalierung für die Last, Aktualisierung von Kubernetes-Versionen und Isolierung von Workloads. Die Knoten selbst sind unveränderlich, sodass Konfigurationsänderungen, die einen Node betreffen, diesen ersetzen, anstatt ihn vor Ort zu ändern.

4.1 Skalierung und Workload-Isolierung

Die Skalierung eines Pools ist eine node_count-Änderung, die über Terraform oder das API angewendet wird. Ein Node-Pool kann bis zu 100 Knoten (20 empfohlen) enthalten, ein Cluster kann bis zu 500 Node Pools (50 empfohlen) und insgesamt bis zu 5000 Knoten enthalten, und jeder Node kann bis zu 110 Pods mit bis zu 20 angehängten Volumes ausführen. Verwenden Sie separate Pools, um Workloads zu isolieren, beispielsweise einen Dedicated-Core-Pool für die latenzsensitiven API und einen vCPU-Pool für den Hintergrund-Worker.

resource "ionoscloud_k8s_node_pool" "worker" {
  name           = "taskboard-worker-pool"
  k8s_cluster_id = ionoscloud_k8s_cluster.taskboard.id
  datacenter_id  = ionoscloud_datacenter.taskboard.id
  k8s_version    = ionoscloud_k8s_cluster.taskboard.k8s_version
  server_type    = "vCPU"
  node_count     = 2
  cores_count    = 2
  ram_size       = 4096
  storage_type   = "SSD"
  storage_size   = 50
}

Planen Sie die Worker-Bereitstellung auf diesen Pool mit einem nodeSelector, der mit dem Pool übereinstimmt, und halten Sie sie von den API-Knoten fern.

4.2 Versionen aktualisieren

Erhöhen Sie den k8s_version auf dem Node-Pool, um zu aktualisieren. Der Vorgang richtet die Ressourcen im Ziel-Rechenzentrum aus, und der Pool kehrt zu Active zurück, wenn der Vorgang abgeschlossen ist, aber er läuft während der Wartung und kann Verbindungsabbrüche verursachen, also sollten Sie dies absichtlich tun. Halten Sie die Kontrollflugzeug-Minor-Version und die Node-Pool-Versionen innerhalb des unterstützten Skews, und aktualisieren Sie die Kontrollflugzeug vor den Node Pools.

ionosctl k8s nodepool update \
  --cluster-id <cluster-id> \
  --nodepool-id <nodepool-id> \
  --k8s-version 1.34

Permanente Volumes werden durch den IONOS-CSI-Treiber (cloud.ionos.com-Provisionierer) bereitgestellt, der von Block Storage unterstützt wird, sodass Pods mit PVCs während einer Aktualisierung auf Ersatzknoten neu geplant werden, ohne dass Daten verloren gehen.

5. Fehlerbehebung bei Workloads auf MKS

Wenn eine Bereitstellung nicht wie erwartet funktioniert, arbeiten Sie von der Pod-Ebene nach außen. Die Standard-kubectl-Triage-Kette gilt, aber eine Plattformlücke ändert Ihre Strategie: Kubernetes-Steuerungsebenen-Ereignisse fließen nicht durch die IONOS Logging Service, also erwarten Sie nicht, dass Sie Scheduler- oder API-Server-Protokolle dort finden.

5.1 Die Triage-Kette

# pod status and restart counts
kubectl get pods -n taskboard -o wide

# why a pod is stuck (events at the bottom)
kubectl describe pod taskboard-api-7d9f -n taskboard

# application stdout/stderr, including the previous crashed container
kubectl logs taskboard-api-7d9f -n taskboard --previous

# cluster-scoped events, newest last
kubectl get events -n taskboard --sort-by=.lastTimestamp

# shell into a running container to test connectivity
kubectl exec -it taskboard-api-7d9f -n taskboard -- sh

kubectl describe ist der Ort, an dem ImagePullBackOff, fehlgeschlagene Planung und Sondierungsfehler auftauchen, also lesen Sie es, bevor Sie nach Protokollen suchen. Für die Anwendungs-Beobachtbarkeit leiten Sie Ihre eigenen Container-Protokolle explizit an die Logging Service weiter, da die Plattform keine Steuerungsebenen-Signale für Sie erfassen wird.

5.2 Kenntnis der Plattform-Grenze

Wenn Sie annehmen, dass Steuerungsebenen-Ereignisse zentral protokolliert werden, werden Sie Stunden damit verbringen, einen Datenstrom zu durchsuchen, der sie nie enthielt. Konfigurieren Sie die Cluster-Ebene-Protokollweiterleitung (zum Beispiel ein Fluent Bit DaemonSet, das Pod-Protokolle an die Logging Service sendet) für die Anwendungsprotokolle, die Sie kontrollieren, und verlassen Sie sich auf kubectl get events für die Sichtbarkeit der Steuerungsebene. Kombinieren Sie dies mit den Bereitschafts- und Lebensfähigkeits-Sonden aus Abschnitt 2, damit die Cluster ungültige Pods automatisch neu startet und neu plant, während Sie untersuchen.

API Referenz-Quick-Card

Wichtige API-Endpunkte für Managed Kubernetes:

Basis-URL: https://api.ionos.com/cloudapi/v6 Authentifizierung: Authorization: Bearer <token>

Code-Labor

Ziel: Bereitstellung eines MKS Cluster mit Terraform, Bereitstellung von TaskBoards API von Private Container Registry und Erreichbarkeit über einen Ingress-Controller.

Voraussetzungen:

• IONOS Cloud-Konto mit API-Token (IONOS_TOKEN exportiert)
• Terraform und der ionos-cloud/ionoscloud-Anbieter
• kubectl und ionosctl installiert
• Ein Private Container Registry mit dem taskboard-api-Image hochgeladen (Einheit 3.1)

Schritt 1: Bereitstellung des Cluster- und Node-Pools

terraform init
terraform apply -auto-approve

Erwartete Ausgabe:

ionoscloud_k8s_cluster.taskboard: Creation complete
ionoscloud_k8s_node_pool.app: Creation complete
Apply complete! Resources: 2 added.

Schritt 2: Schreiben der kubeconfig und Verbindung herstellen

terraform output -raw kubeconfig > kubeconfig.yaml
chmod 600 kubeconfig.yaml
export KUBECONFIG=$(pwd)/kubeconfig.yaml
kubectl get nodes

Erwartete Ausgabe:

NAME                  STATUS   ROLES    AGE   VERSION
taskboard-app-pool-1  Ready    <none>   2m    v1.34.x
taskboard-app-pool-2  Ready    <none>   2m    v1.34.x
taskboard-app-pool-3  Ready    <none>   2m    v1.34.x

Schritt 3: Erstellen von Namespace und Registry-Pull-Geheimnis

kubectl create namespace taskboard
kubectl create secret docker-registry registry-cred \
  --namespace taskboard \
  --docker-server=<registry-name>.cr.de-fra.ionos.com \
  --docker-username=<token-name> \
  --docker-password=<registry-token>

Erwartete Ausgabe:

namespace/taskboard created
secret/registry-cred created

Schritt 4: Bereitstellung des API, ConfigMap und Secret

kubectl apply -f taskboard-api.yaml
kubectl rollout status deployment/taskboard-api -n taskboard

Erwartete Ausgabe:

deployment "taskboard-api" successfully rolled out

Schritt 5: Überprüfen, ob Pods abgerufen und ausgeführt werden

kubectl get pods -n taskboard

Erwartete Ausgabe:

NAME                            READY   STATUS    RESTARTS   AGE
taskboard-api-7d9f8c-abcde      1/1     Running   0          40s
taskboard-api-7d9f8c-fghij      1/1     Running   0          40s
taskboard-api-7d9f8c-klmno      1/1     Running   0          40s

Schritt 6: Exponieren des Ingress-Controllers und Lesen seiner IP

kubectl apply -f ingress.yaml
kubectl get svc ingress-nginx -n ingress

Erwartete Ausgabe:

NAME            TYPE           EXTERNAL-IP      PORT(S)
ingress-nginx   LoadBalancer   <reserved-ip>    443:3xxxx/TCP

Schritt 7: Bestätigen, dass der Endpunkt antwortet

curl -sk https://<reserved-ip>/healthz

Erwartete Ausgabe:

{"status":"ok"}

Validierungs-Checkliste:

• [ ] Cluster- und Node-Pool erreichen Active und Knoten sind Ready
• [ ] API-Pods sind Running, nicht ImagePullBackOff
• [ ] Die Ingress-IP gibt eine gesunde Antwort vom API zurück

Aufräumen:

kubectl delete namespace taskboard
terraform destroy -auto-approve

Häufige Fehlerquellen

Entwicklerfehler, die bei der Bereitstellung in MKS vermieden werden sollten:

1. Erwartung, dass type: LoadBalancer Ihnen eine echte externe Load Balancer gibt

   • Problem: Sie legen jeden Dienst als LoadBalancer offen, erwarten Hochverfügbarkeit über Knoten hinweg und die Quell-IPs erscheinen alle als eine einzelne Node-Adresse.
   • Warum es passiert: In MKS reserviert ein LoadBalancer-Dienst eine statische IP und bindet sie an einen Worker-Node als sekundäre IP; kube-proxy NATs zum Pod und die Quell-IP geht verloren.
   • Lösung: Legen Sie nur den Ingress-Controller als LoadBalancer offen, setzen Sie externalTrafficPolicy: Local, um die Quell-IP zu erhalten, und stellen Sie den Produktionsverkehr mit einem separat bereitgestellten ALB bereit:

   spec:
     type: LoadBalancer
     externalTrafficPolicy: Local
   

2. ImagePullBackOff aufgrund eines fehlenden oder falsch angebundenen Pull-Geheimnisses

   • Problem: Pods starten nie; kubectl describe pod zeigt Failed to pull image ... no basic auth credentials.
   • Warum es passiert: Private Container Registry erfordert bei jedem Pull eine Authentifizierung, und das dockerconfigjson-Geheimnis ist namensgebunden. Ein Geheimnis in default hat keine Auswirkungen auf Pods in taskboard.
   • Lösung: Erstellen Sie das Registrierungs-Geheimnis im Namensraum des Workload und verweisen Sie darauf unter imagePullSecrets:

   kubectl create secret docker-registry registry-cred -n taskboard \
     --docker-server=<registry-name>.cr.de-fra.ionos.com \
     --docker-username=<token-name> --docker-password=<registry-token>
   

3. Suchen nach Logging Service-Steuerungsebenen-Ereignissen

   • Problem: Ein Pod wird nicht geplant und Sie verbringen eine Stunde damit, zentrale Protokolle nach Planungsfehlern zu durchsuchen, die nicht vorhanden sind.
   • Warum es passiert: Kubernetes-Steuerungsebenen-Ereignisse fließen nicht durch die IONOS-Logging Service.
   • Lösung: Lesen Sie Steuerungsebenen-Signale mit kubectl und leiten Sie nur die Anwendungsprotokolle weiter, die Sie kontrollieren:

   kubectl get events -n taskboard --sort-by=.lastTimestamp
   kubectl describe pod <pod> -n taskboard
   

Zusammenfassung

Sie können jetzt eine Managed Kubernetes Cluster und Node Pools vollständig als Code bereitstellen, die kubeconfig von Terraform-Zustand abrufen und Container-Anwendungen bereitstellen, die von Private Container Registry abrufen. Sie wissen auch die zwei IONOS-Realitäten, die eine funktionierende MKS-Bereitstellung von einer defekten unterscheiden: Der LoadBalancer-Service-Typ ist kein echter externer Load Balancer, sodass der Produktionsverkehr von einem separat bereitgestellten ALB vermittelt wird, und Steuerungsereignisse werden nicht zentral protokolliert, sodass die Fehlerbehebung über kubectl plus Ihre eigene Log-Weiterleitung läuft.

Mit TaskBoards API, Frontend und Worker, die auf MKS hinter einem ALB ausgeführt werden, haben Sie ein bereitstellbares Ziel. Die nächste Einheit automatisiert den Weg von einem Git-Commit zu diesem laufenden Cluster.

Wichtige Punkte:

• Die MKS-Steuerungsebene ist kostenlos; Sie zahlen nur für Node-Pool-Rechenressourcen und Block Storage-Volumen
• Rufen Sie die kubeconfig vom ionoscloud_k8s_cluster-Ressourcen-kube_config-Attribut ab, das als sensitiv markiert ist
• Ein type: LoadBalancer-Service bindet eine statische IP an einen Worker-Node und ist kein echter externer LB; vermitteln Sie den Produktionsverkehr mit einem separat bereitgestellten ALB
• Ziehen Sie private Bilder mit einem namensgebundenen docker-registry-Geheimnis, das als imagePullSecrets referenziert wird
• Kubernetes-Steuerungsereignisse erreichen nicht das IONOS-Logging Service; debuggen Sie mit kubectl und leiten Sie die Anwendungsprotokolle selbst weiter

Wichtige Begriffe:

• Node-Pool: Eine Gruppe von Worker Nodes eines Servertyps in einem Rechenzentrum, die als Einheit skaliert und aktualisiert wird (bis zu 100 Knoten, 20 empfohlen)
• kubeconfig: Die Anmelde- und Verbindungsdaten für kubectl, die durch die Cluster-Ressource bereitgestellt und als Geheimnis behandelt werden
• imagePullSecrets: Ein Pod-Spezifikationsverweis auf ein dockerconfigjson-Geheimnis, das die Authentifizierung von Abrufen von Private Container Registry ermöglicht
• externalTrafficPolicy: Local: Eine Service-Einstellung, die die Client-Quell-IP durch die Beibehaltung des Verkehrs auf dem empfangenden Node anstelle der Umleitung beibehält
• CSI-Bereitsteller (cloud.ionos.com): Der IONOS-Speichertreiber, der PersistentVolumeClaims mit Block Storage unterstützt, sodass die Daten den Node-Ersatz überleben

Nächste Schritte

Weiterlernen: Einheit 3.3: CI/CD Pipelines für IONOS

Verwandte Themen:

• Einheit 3.1: Container Registry und Image-Pipelines
• Einheit 5.1: Beobachtbarkeit und Debugging