Einheit 3.2: Kubernetes-Deployment und Betrieb

Einführung

In Einheit 3.1 haben Sie die API, das Frontend und den Worker von TaskBoard containerisiert und mit git-SHA-Tags in die Private Container Registry hochgeladen. Jetzt benötigen Sie einen Ort, um sie auszuführen. In dieser Einheit provisionieren Sie einen Managed Kubernetes (MKS)-Cluster als Code, verdrahten die Registry-Zugangsdaten in den Cluster, damit er Ihre Images abrufen kann, und deployen alle drei Dienste als standardmäßige Kubernetes-Ressourcen.

Die Steuerungsebene von MKS wird für Sie verwaltet, aber zwei IONOS CLOUD-spezifische Gegebenheiten prägen jeden Deployment, den Sie schreiben. Erstens provisioniert ein Service vom Typ LoadBalancer auf MKS keinen echten externen Load Balancer, sodass der Produktions-Ingress durch einen separat provisionierten Application Load Balancer (ALB) abgesichert wird. Zweitens sind die Steuerungsebenen-Ereignisse, die Sie in einem zentralen Log-Stream erwarten könnten, nicht vorhanden, was Ihre Debugging-Methodik verändert. Sie schreiben Code für beide Gegebenheiten, anstatt sie nachträglich zu umgehen, wenn sie sich in der Produktion bemerkbar machen.

1. Bereitstellung des Clusters mit Terraform

Ein Managed Kubernetes-Cluster in IONOS CLOUD besteht aus zwei unterschiedlichen Ressourcen: dem Cluster (die verwaltete Steuerungsebene) und einem oder mehreren Node Pools (die Worker-Rechenleistung, für die Sie zahlen). Die Steuerungsebene selbst ist kostenlos; Sie zahlen nur für die zugrunde liegende Rechenleistung der Node Pools und die Block Storage-Volumes, die Ihre Pods bereitstellen. Erstellen Sie zuerst den Cluster und hängen Sie dann Node Pools an, die auf ihn 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 in einem bestimmten Rechenzentrum.

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, anstatt die neueste Version zu verfolgen, da jede Node-Pool-Aktualisierung während des Wartungsfensters ausgeführt wird und Verbindungsabbrüche verursachen kann. Node-Pools akzeptieren sowohl DedicatedCore- als auch vCPU-Servertypen. Dimensionieren Sie den App-Pool von TaskBoard daher auf Dedicated Core, um eine vorhersehbare Leistung zu gewährleisten.

1.2 Abrufen der kubeconfig aus dem State

Die kubeconfig kann aus der DCD-Oberfläche heruntergeladen werden. Das Cluster-Ressourcenobjekt stellt die Konfiguration jedoch auch direkt bereit, sodass Terraform sie auf die Festplatte schreiben kann, damit kubectl und CI sie verwenden können.

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 vollen Clusterzugriff. Markieren Sie die Terraform-Ausgabe sensitive und commiten Sie die generierte Datei niemals.

2. Deployment von Workloads in MKS

Sobald kubectl den Cluster erreicht, verhält sich MKS wie ein standardmäßiges Upstream-Kubernetes. Es gibt keinen IONOS CLOUD-spezifischen Manifest-Dialekt. Sie wenden Deployments, Services, ConfigMaps und Secrets genau so an, wie Sie es auf jedem konformen Cluster tun würden. Das CNI ist Calico und fest vorgegeben, daher folgt die Erstellung von Netzwerkrichtlinien der Calico-Semantik, ohne die Möglichkeit, das Plugin zu wechseln.

2.1 Deployment, ConfigMap und Secret

Die API von TaskBoard benötigt nicht geheime Konfigurationen und geheime Zugangsdaten. Trennen Sie diese: eine ConfigMap für den Datenbankhost und Feature-Flags, 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 werden in MKS bei der Speicherung verschlüsselt, aber Kubernetes Secrets werden im Manifest lediglich base64-kodiert. Daher sollten die Quelldaten weiterhin aus Git herausgehalten und beim Deployment aus der Terraform-Ausgabe injiziert werden. Der Readiness-Probe kommt eine wichtige Rolle zu, da rollierende Updates auf sie warten, bevor der Verkehr umgeleitet wird.

2.2 Bilder mit imagePullSecrets abrufen

Private Container Registry erfordert für jeden Abruf eine Authentifizierung. Es handelt sich dabei um eine tokenbasierte docker login ohne RBAC und ohne teamweise Repositories. Kubernetes benötigt ein dockerconfigjson Secret, das aus einem Registry-Token erstellt wird und im oben genannten Pod-Spec 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 Verweis imagePullSecrets weglassen oder das Secret in den falschen Namespace einbinden, bleiben Pods in ImagePullBackOff stehen. Da das Secret namespacebezogen ist, erstellen Sie es in jedem Namespace, in dem Registry-Images ausgeführt werden. In CI erzeugen Sie das Registry-Token einmalig und speichern es als Pipeline-Secret. Anschließend erstellen Sie das Kubernetes Secret als Deployment-Schritt.

3. Traffic freizugeben: die Realität des LoadBalancers

Dies ist die wichtigste IONOS CLOUD-spezifische Tatsache in dieser Einheit. Ein Service vom Typ LoadBalancer auf MKS provisioniert keinen echten externen Load Balancer. IONOS CLOUD reserviert eine statische öffentliche IP und weist sie als sekundäre IP einem Worker Node zu, der zum Ingress-Node wird. kube-proxy leitet den Traffic anschließend per NAT an das Zielpod weiter.

3.1 Was das für Ihre Manifeste bedeutet

Daraus ergeben sich zwei unmittelbare Konsequenzen. Die Quell-IP des Clients geht verloren, sofern Sie externalTrafficPolicy: Local nicht setzen. Außerdem ist die Durchsatzrate auf die öffentliche Obergrenze von 2 Gbit/s dieses einzelnen Ingress-Nodes begrenzt, da der gesamte Traffic über einen einzigen Node geleitet wird. Für diese IP gibt es keinen automatischen Hochverfügbarkeitsbetrieb über mehrere Nodes.

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 Traffic über einen einzelnen Knoten hinaus zu skalieren, reservieren Sie mehrere LB-IP-Adressen und verteilen sie über mehrere Ingress-Knoten mittels DNS-Lastverteilung. Da nur öffentliche Node Pools den Service-Typ LoadBalancer überhaupt unterstützen (private Node Pools tun dies nicht), halten Sie Ihren internetzugewandten Ingress-Controller auf einem öffentlichen Pool. Exponieren Sie ausschließlich den Ingress-Controller als LoadBalancer, niemals einen Service pro App.

3.2 Fronting des Clusters mit einem separat provisionierten ALB

Für die produktionsreife TaskBoard-Instanz provisionieren Sie einen Application Load Balancer separat über Terraform. Der ALB wird nicht automatisch aus einem Kubernetes-Manifest erstellt, sodass es keine Ingress-Controller-Annotation gibt, die einen solchen erzeugt. Sie provisionieren ihn als Infrastruktur und richten seine Weiterleitungsregeln auf die IP-Adressen der Knoten aus, die den Ingress-Controller bereitstellen.

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 für den ALB gelten. Network Security Groups werden auf der Ebene der Server-NIC gebunden, nicht an den Managed ALB oder an MKS. Daher steuern Sie den eingehenden Verkehr über die Weiterleitungsregeln des ALB und die Sicherheitsregeln auf den NICs der Worker-Nodes, indem Sie keine NSG an den Load Balancer anbinden.

4. Node Pool Operationen

Node Pools sind die operative Oberfläche, die Sie über die gesamte Lebensdauer des Clusters verwalten: Skalierung für Last, Upgrades von Kubernetes-Versionen und die Isolation von Workloads. Die Nodes selbst sind unveränderlich, daher ersetzen Konfigurationsänderungen, die einen Node betreffen, diesen, anstatt ihn an Ort und Stelle zu modifizieren.

4.1 Skalierung und Workload-Isolation

Die Skalierung eines Pools ist eine node_count-Änderung, die über Terraform oder die API angewendet wird. Ein Node Pool hält bis zu 100 Nodes (20 empfohlen), ein Cluster hält bis zu 500 Node Pools (50 empfohlen) und insgesamt bis zu 5000 Nodes, und jeder Node führt bis zu 110 Pods mit bis zu 20 angehängten Volumes aus. 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 das Deployment der Worker auf diesem Pool mit einem nodeSelector, das dem Pool entspricht, so dass es von den API-Knoten ferngehalten wird.

4.2 Versions-Upgrades

Erhöhen Sie k8s_version im Node-Pool, um ein Upgrade durchzuführen. Der Vorgang richtet die Ressourcen im Ziel-Rechenzentrum aus, und der Pool kehrt nach Abschluss in den Zustand Active zurück. Der Vorgang wird jedoch während der Wartung ausgeführt und kann zu Verbindungsabbrüchen führen, daher sollte er bewusst durchgeführt werden. Halten Sie die Minor-Version der Steuerungsebene und die Versionen der Node-Pools innerhalb der unterstützten Abweichung und führen Sie das Upgrade der Steuerungsebene vor dem Upgrade der Node-Pools durch.

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

Dauerhafte Volumes werden vom IONOS CLOUD CSI-Treiber (cloud.ionos.com Provisioner) bereitgestellt, der auf Block Storage basiert. Dadurch werden Pods mit PVCs während eines Upgrades auf Ersatzknoten neu eingeplant, ohne dass Daten verloren gehen.

5. Debugging von Workloads auf MKS

Wenn ein Deployment nicht wie erwartet funktioniert, arbeiten Sie vom Pod nach außen. Die Standard-kubectl-Triage-Kette gilt weiterhin, aber eine Lücke in der Plattform ändert Ihre Strategie: Ereignisse der Kubernetes-Control-Plane werden nicht über den IONOS CLOUD Logging Service geleitet, daher sollten Sie dort keine Scheduler- oder API-Server-Protokolle erwarten.

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 Scheduling-Vorgänge und Probe-Fehler sichtbar werden. Lesen Sie daher zuerst diesen Bereich, bevor Sie auf Protokolle zurückgreifen. Für anwendungsebene Observability leiten Sie Ihre eigenen Container-Protokolle explizit an den Logging Service weiter, da die Plattform keine Control-Plane-Signale für Sie erfasst.

5.2 Die Plattformgrenze kennen

Wenn Sie davon ausgehen, dass Control-Plane-Ereignisse zentral protokolliert werden, werden Sie Stunden damit verbringen, in einem Datenstrom zu suchen, der sie nie enthalten hat. Richten Sie für die Anwendungsprotokolle, die Sie kontrollieren, eine clusterweite Protokollweiterleitung ein (zum Beispiel ein Fluent Bit DaemonSet, das Pod-Protokolle an den Logging Service sendet), und verlassen Sie sich für die Sichtbarkeit der Control-Plane auf kubectl get events. Kombinieren Sie dies mit den Readiness- und Liveness-Probes aus Abschnitt 2, damit der Cluster nicht gesunde Pods automatisch neu startet und neu plant, während Sie die Ursache untersuchen.

API-Referenz-Schnellkarte

Wichtige API-Endpunkte für Managed Kubernetes:

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

Code Lab

Ziel: Provisionierung eines MKS-Clusters mit Terraform, Bereitstellung der API von TaskBoard aus der Private Container Registry und Zugriff über einen Ingress-Controller.

Voraussetzungen:

• IONOS CLOUD-Konto mit API-Token (IONOS_TOKEN exportiert)
• Terraform und der ionos-cloud/ionoscloud-Provider
• kubectl und ionosctl installiert
• Eine Private Container Registry, in die das taskboard-api-Image hochgeladen wurde (Einheit 3.1)

Schritt 1: Cluster und Node-Pool provisionieren

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: kubeconfig schreiben 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: Namespace und Registry-Pull-Secret erstellen

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: API, ConfigMap und Secret deployen

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

Erwartete Ausgabe:

deployment "taskboard-api" successfully rolled out

Schritt 5: Prüfen, ob Pods gezogen 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: Den Ingress-Controller freigeben und seine IP abrufen

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"}

Prüfliste:

• [ ] Cluster und Node Pool erreichen Active und die Nodes sind Ready
• [ ] API-Pods sind Running, nicht ImagePullBackOff
• [ ] Die Ingress-IP liefert eine gesunde Antwort von der API

Aufräumarbeiten:

kubectl delete namespace taskboard
terraform destroy -auto-approve

Häufige Fehler

Fehler von Entwicklerinnen und Entwicklern, die bei der Bereitstellung auf MKS zu vermeiden sind:

1. Die Erwartung, dass type: LoadBalancer einen echten externen Load Balancer bereitstellt

   • Problem: Sie stellen jeden Service als LoadBalancer bereit, erwarten Hochverfügbarkeit über mehrere Knoten hinweg, und die Quell-IP-Adressen werden alle als eine einzelne Knotenadresse angezeigt.
   • Ursache: Auf MKS reserviert ein LoadBalancer-Service eine statische IP und weist sie als sekundäre IP einem einzelnen Worker-Knoten zu; kube-proxy wendet NAT auf den Pod an, und die Quell-IP-Adresse geht verloren.
   • Lösung: Stellen Sie nur den Ingress-Controller als LoadBalancer bereit, setzen Sie externalTrafficPolicy: Local, um die Quell-IP-Adresse beizubehalten, und leiten Sie den Produktivverkehr über einen separat bereitgestellten ALB:

   spec:
     type: LoadBalancer
     externalTrafficPolicy: Local
   

2. ImagePullBackOff durch ein fehlendes oder falsch zugewiesenes Pull-Secret

   • Problem: Pods starten nie; kubectl describe pod zeigt Failed to pull image ... no basic auth credentials.
   • Ursache: Private Container Registry erfordert bei jedem Pull eine Authentifizierung, und das dockerconfigjson Secret ist namespace-basiert. Ein Secret in default hat keine Wirkung für Pods in taskboard.
   • Lösung: Erstellen Sie das Registry-Secret im Namespace der 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. Suche im Logging Service nach Control-Plane-Ereignissen

   • Problem: Ein Pod wird nicht eingeplant, und Sie verbringen eine Stunde damit, in den zentralen Logs nach Scheduler-Fehlern zu suchen, die dort nicht vorhanden sind.
   • Ursache: Kubernetes-Control-Plane-Ereignisse fließen nicht durch den IONOS CLOUD Logging Service.
   • Lösung: Lesen Sie Control-Plane-Signale mit kubectl und leiten Sie nur die Anwendungstage weiter, die Sie kontrollieren:

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

Zusammenfassung

Sie können nun einen Managed Kubernetes-Cluster und Node-Pools vollständig als Code bereitstellen, die kubeconfig aus dem Terraform-Zustand abrufen und containerisierte Dienste bereitstellen, die aus der Private Container Registry ziehen. Sie kennen auch die beiden IONOS CLOUD-Realitäten, die eine funktionierende MKS-Bereitstellung von einer fehlerhaften trennen: Der LoadBalancer-Diensttyp ist kein echter externer Load Balancer, daher wird der Produktivverkehr durch einen separat bereitgestellten ALB abgewickelt, und Steuerungsebenen-Ereignisse werden nicht zentral protokolliert, sodass die Fehlersuche über kubectl plus Ihre eigene Log-Weiterleitung erfolgt.

Mit der TaskBoard-API, dem Frontend und dem Worker, die auf MKS hinter einem ALB laufen, haben Sie ein bereitstellungsfähiges Ziel. Die nächste Einheit automatisiert den Weg von einem Git-Commit zu diesem laufenden Cluster.

Wichtige Punkte:

• Die Steuerungsebene von MKS ist kostenlos; Sie zahlen nur für die Rechenleistung der Node-Pools und Block Storage-Volumes
• Rufen Sie die kubeconfig über das kube_config-Attribut der ionoscloud_k8s_cluster-Ressource ab, das als sensibel markiert ist
• Ein type: LoadBalancer-Dienst bindet eine statische IP an einen Worker-Node und ist kein echter externer LB; stellen Sie den Produktivverkehr mit einem separat bereitgestellten ALB bereit
• Ziehen Sie private Images mit einem namensraumqualifizierten docker-registry-Secret, das als imagePullSecrets referenziert wird
• Kubernetes-Steuerungsebenen-Ereignisse erreichen den IONOS CLOUD Logging Service nicht; debuggen Sie mit kubectl und leiten Sie Anwendungslogs 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 Nodes, 20 empfohlen)
• kubeconfig: Die Authentifizierungs- und Verbindungsdatei für kubectl, die von der Cluster-Ressource bereitgestellt und als Geheimnis behandelt wird
• imagePullSecrets: Eine Pod-Spezifikationsreferenz auf ein dockerconfigjson-Secret, das das Ziehen aus der Private Container Registry authentifiziert
• externalTrafficPolicy: Local: Eine Dienst-Einstellung, die die Client-Quell-IP erhält, indem der Verkehr auf dem empfangenden Node gehalten wird, anstatt ihn neu zu routen
• CSI-Provisioner (cloud.ionos.com): Der IONOS CLOUD-Speicher-Treiber, der PersistentVolumeClaims mit Block Storage hinterlegt, damit Daten bei Node-Ersatz erhalten bleiben

Nächste Schritte

Weiter lernen: Einheit 3.3: CI/CD-Pipelines für IONOS CLOUD

Verwandte Themen:

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