Zustandsorientierte Arbeitslasten erstellen

In diesem Dokument wird beschrieben, wie Sie zustandsorientierte Arbeitslasten in einem GDC-Kubernetes-Cluster (Google Distributed Cloud) mit Air Gap erstellen und verwalten. Mit zustandsorientierten Arbeitslasten können Sie das Deployment Ihrer Anwendung mit nichtflüchtigem Speicher skalieren. Nichtflüchtiger Speicher bietet Ihrer Anwendung konsistente Identitäten und stabile Hostnamen, unabhängig davon, wo die Arbeitslasten geplant sind.

Dieses Dokument richtet sich an Entwickler in der Gruppe der Anwendungsoperatoren, die für die Erstellung von Anwendungsarbeitslasten für ihre Organisation verantwortlich sind. Weitere Informationen finden Sie unter Dokumentation zu Zielgruppen für GDC mit Air Gap.

Hinweis

Um die Aufgaben in diesem Dokument auszuführen, müssen Sie die erforderlichen Berechtigungen anfordern und Ihre Umgebung vorbereiten.

IAM-Rollen anfordern

Sie benötigen bestimmte Rollen, um die Berechtigungen zu erhalten, die zum Erstellen zustandsorientierter Arbeitslasten erforderlich sind. Die erforderlichen Rollen hängen davon ab, ob Sie in einem gemeinsam genutzten Cluster mit Organisationsbereich oder in einem Standardcluster mit Projektbereich arbeiten. Weitere Informationen finden Sie unter Kubernetes-Clusterkonfigurationen.

Rollen für gemeinsam genutzte Cluster

Wenn Sie zustandsorientierte Arbeitslasten in einem gemeinsam genutzten Cluster erstellen, löschen, bearbeiten oder ansehen möchten, bitten Sie Ihren Projekt-IAM-Administrator, Ihnen die Rolle Namespace-Administrator (namespace-admin) zuzuweisen. Diese Rolle ist an Ihren Projekt-Namespace gebunden.

Rollen für Standardcluster

Wenn Sie zustandsorientierte Arbeitslasten in einem Standardcluster erstellen, löschen, bearbeiten oder ansehen möchten, bitten Sie Ihren Projekt-IAM-Administrator, Ihnen die Rolle Cluster Developer (cluster-developer) zuzuweisen. Diese Rolle ist an Ihren Projekt-Namespace gebunden.

Umgebung vorbereiten

Wenn Sie Befehle für einen Kubernetes-Cluster mit der API ausführen möchten, benötigen Sie die folgenden Ressourcen:

  • Suchen Sie den Namen des Kubernetes-Clusters oder fragen Sie ein Mitglied der Gruppe der Plattformadministratoren nach dem Clusternamen.

  • Melden Sie sich an und generieren Sie die kubeconfig-Datei für den Kubernetes-Cluster.

  • Ersetzen Sie in dieser Anleitung KUBERNETES_CLUSTER_KUBECONFIG durch den kubeconfig-Pfad des Kubernetes-Clusters.

StatefulSet-Ressource erstellen

Erstellen Sie ein StatefulSet-Objekt, indem Sie ein StatefulSet-Manifest schreiben und kubectl apply ausführen, um die Ressource zu erstellen. Damit Clients Anfragen stabil an die Pods Ihrer StatefulSet-Ressource senden können, müssen Sie auch ein Service-Objekt erstellen.

Der Befehl kubectl apply verwendet Manifestdateien, um Ressourcen in Ihrem Kubernetes-Cluster zu erstellen, zu aktualisieren und zu löschen. Dies ist eine deklarative Methode der Objektkonfiguration. Bei dieser Methode werden Schreibvorgänge in Liveobjekten beibehalten, ohne die Änderungen in die Objektkonfigurationsdateien zu übernehmen.

Führen Sie Folgendes aus, um eine StatefulSet- und eine Service-Ressource zu erstellen:

kubectl --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG -n NAMESPACE \
    apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME
  labels:
    app: APP_NAME
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: APP_NAME
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: STATEFULSET_NAME
spec:
  selector:
    matchLabels:
      app: APP_LABEL_NAME
  serviceName: "SERVICE_NAME"
  replicas: NUMBER_OF_REPLICAS
  template:
    metadata:
      labels:
        app: APP_LABEL_NAME
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: CONTAINER_NAME
        image: CONTAINER_IMAGE
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: CONTAINER_STORAGE_VOLUME_PATH
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi
EOF

Ersetzen Sie Folgendes:

  • KUBERNETES_CLUSTER_KUBECONFIG: Die kubeconfig-Datei für den Cluster, in dem Sie Containerarbeitslasten bereitstellen.

  • NAMESPACE: Der Namespace, in dem die Containerarbeitslasten bereitgestellt werden sollen. Bei gemeinsam genutzten Clustern muss dies ein Projekt-Namespace sein. Bei Standardclustern kann es ein beliebiger Namespace sein.

  • SERVICE_NAME: Der Name des Service-Objekts. Achten Sie darauf, dass das StatefulSet-Objekt das Service-Objekt auch in seinem serviceName festlegt.

  • APP_NAME: Der Name der Anwendung, die im Deployment ausgeführt werden soll.

  • APP_LABEL_NAME: Der Label-Selektor, der bestimmt, welche Pods zum StatefulSet-Objekt gehören.

  • STATEFULSET_NAME: Der Name des StatefulSet-Objekts.

  • NUMBER_OF_REPLICAS: Die Anzahl der replizierten Pod-Objekte, die vom Deployment verwaltet werden.

  • CONTAINER_NAME: Der Name des Containers.

  • CONTAINER_IMAGE: Der Name des Container-Images. Sie müssen den Container Registry-Pfad und die Version des Images angeben, z. B. REGISTRY_PATH/nginx:1.23. Weitere Informationen zum Festlegen des Container Registry-Pfads finden Sie in der Übersicht zum Managed Harbor Service.

  • CONTAINER_STORAGE_VOLUME_PATH: Der Pfad innerhalb des Containers, in dem ein Speichervolume bereitgestellt wird.

Das folgende StatefulSet-Objekt und das entsprechende Service-Objekt erstellen beispielsweise zustandsorientierte Containerarbeitslasten:

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: REGISTRY_PATH/nginx:1.23
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

In diesem Fall gilt Folgendes:

  • Ein Service-Objekt mit dem Namen nginx wird erstellt, wie durch das Feld metadata: name angegeben. Das Service Objekt zielt auf eine App namens nginx, wie durch labels.app: nginx und selector.app: nginx angegeben. Das Service-Objekt macht Port 80 verfügbar und nennt ihn web. Dieses Service-Objekt steuert die Netzwerkdomain und leitet den Internettraffic an die vom StatefulSet-Objekt bereitgestellte containerisierte Anwendung weiter.
  • Ein StatefulSet mit dem Namen web wird mit drei replizierten Pod-Objekten erstellt, wie durch das Feld replicas: 3 festgelegt.
  • Die Pod-Vorlage, die durch den Abschnitt .spec.template festgelegt wird, gibt an, dass die Pod-Objekte mit app: nginx gekennzeichnet sind.
  • Die Pod-Spezifikation, die durch den Abschnitt .template.spec festgelegt wird, gibt an, dass die Pods des StatefulSet einen Container (nginx) ausführen, der das nginx-Image in Version 1.23 ausführt.
  • Die Pod-Spezifikation verwendet den Webport, der vom Service-Objekt geöffnet wurde.
  • Im Abschnitt .template.spec.volumeMounts wird ein Feld mountPath mit dem Namen www angegeben. Der mountPath ist der Pfad im Container, in dem ein Speichervolume bereitgestellt wird.
  • Das StatefulSet stellt drei PersistentVolumeClaim-Objekte mit den Namen web-www-0, web-www-1 und web-www-2 mit jeweils 1 GB bereitgestelltem Speicher bereit.

Nach der Erstellung sorgt das StatefulSet dafür, dass die Zielanzahl von Pod-Objekten jederzeit ausgeführt und verfügbar ist. Das StatefulSet ersetzt automatisch Pod-Objekte, die fehlerhaft sind oder aus ihren Knoten entfernt wurden, und ordnet den Speicherressourcen, Ressourcenanfragen und -limits sowie anderen in der Pod-Spezifikation des StatefulSet-Objekts definierten Konfigurationen automatisch neue Pod-Objekte zu.

Nichtflüchtigen Speicher in einer StatefulSet-Ressource anfordern

Nichtflüchtiger Speicher kann dynamisch bereitgestellt werden, d. h., die zugrunde liegenden Volumes werden nach Bedarf erstellt. Anwendungen fordern unter Umständen nichtflüchtigen Speicher mit einem PersistentVolumeClaim-Objekt an.

In der Regel müssen Sie zusätzlich zum Erstellen des Pod-Objekts PersistentVolumeClaim-Objekte erstellen. StatefulSet-Objekte enthalten jedoch ein volumeClaimTemplates-Array, das die PersistentVolumeClaim-Objekte generiert. Jede StatefulSet-Replik erhält ein eigenes PersistentVolumeClaim-Objekt.

Weitere Informationen finden Sie unter Containerspeicher konfigurieren.

Nächste Schritte