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

Zum Ausführen der Aufgaben in diesem Dokument 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 Sie zum Erstellen zustandsorientierter Arbeitslasten benötigen. Welche Rollen Sie benötigen, hängt davon ab, ob Sie in einem freigegebenen Cluster auf Organisationsebene oder in einem Standardcluster auf Projektebene arbeiten. Weitere Informationen finden Sie unter Kubernetes-Clusterkonfigurationen.

Freigegebene Clusterrollen

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

Standardclusterrollen

Bitten Sie Ihren IAM-Projektadministrator, Ihnen die Rolle Cluster Developer (cluster-developer) zuzuweisen, um zustandsorientierte Arbeitslasten in einem Standardcluster zu erstellen, zu löschen, zu bearbeiten oder anzusehen. Diese Rolle ist an Ihren Projekt-Namespace gebunden.

Umgebung vorbereiten

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

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

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

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

Ressource StatefulSet 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 folgenden Befehl 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 freigegebenen Clustern muss dies ein Projekt-Namespace sein. Bei Standardclustern kann es sich um einen beliebigen Namespace handeln.

  • 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: die Labelauswahl, die 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 über den Managed Harbor Service.

  • CONTAINER_STORAGE_VOLUME_PATH: der Pfad im Container, in dem ein Speicher-Volume bereitgestellt wird.

Im folgenden Beispiel erstellen das StatefulSet-Objekt und das entsprechende Service-Objekt 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:

  • Es wird ein Service-Objekt mit dem Namen nginx erstellt, das durch das Feld metadata: name angegeben wird. Das Objekt Service ist auf eine Anwendung namens nginx ausgerichtet, die durch labels.app: nginx und selector.app: nginx angegeben wird. Das Objekt Service stellt Port 80 bereit und benennt ihn web. Dieses Service-Objekt steuert die Netzwerkdomain und leitet Internettraffic an die containerisierte Anwendung weiter, die vom StatefulSet-Objekt bereitgestellt wird.
  • Es wird ein StatefulSet mit dem Namen web mit drei replizierten Pod-Objekten erstellt, wie im Feld replicas: 3 festgelegt.
  • Die Vorlage Pod, die im Abschnitt .spec.template festgelegt ist, gibt an, dass die Pod-Objekte mit app: nginx gekennzeichnet sind.
  • Die Spezifikation Pod, die im Abschnitt .template.spec festgelegt ist, gibt an, dass die Pods des StatefulSet einen Container namens nginx ausführen, der wiederum das Image nginx mit Version 1.23 ausführt.
  • Die Spezifikation Pod verwendet den vom Objekt Service geöffneten Webport.
  • Im Abschnitt .template.spec.volumeMounts wird ein mountPath-Feld mit dem Namen www angegeben. mountPath ist der Pfad im Container, in dem ein Speicher-Volume 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 ausgeführt wird und jederzeit verfügbar ist. Das StatefulSet-Objekt 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 neue Pod-Objekte zu.

Nichtflüchtigen Speicher in einer StatefulSet-Ressource anfordern

Nichtflüchtiger Speicher kann dynamisch bereitgestellt werden, sodass die zugrunde liegenden Volumes bei Bedarf erstellt werden. Anwendungen können nichtflüchtigen Speicher mit einem PersistentVolumeClaim-Objekt anfordern.

In der Regel müssen Sie zusätzlich zum Pod-Objekt auch PersistentVolumeClaim-Objekte erstellen. StatefulSet-Objekte enthalten jedoch ein volumeClaimTemplates-Array, das die PersistentVolumeClaim-Objekte generiert. Jedes StatefulSet-Replikat erhält ein eigenes PersistentVolumeClaim-Objekt.

Weitere Informationen finden Sie unter Containerspeicher konfigurieren.

Nächste Schritte