Zustandsorientierte Arbeitslasten erstellen

In diesem Dokument wird beschrieben, wie Sie zustandsbehaftete 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 organisationsbezogenen freigegebenen Cluster oder in einem projektbezogenen Standardcluster arbeiten. Weitere Informationen finden Sie unter Kubernetes-Clusterkonfigurationen.

Freigegebene Clusterrollen

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.

Standard-Clusterrollen

Wenn Sie zustandsbehaftete 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 ü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 Gruppe „Plattformadministrator“, wie der Clustername lautet.

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

  • Verwenden Sie den kubeconfig-Pfad des Kubernetes-Clusters, um KUBERNETES_CLUSTER_KUBECONFIG in dieser Anleitung zu ersetzen.

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 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 freigegebenen Clustern muss es sich um einen Projekt-Namespace handeln. 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, unter dem ein Speichervolume bereitgestellt wird.

Das folgende StatefulSet-Objekt und das entsprechende Service-Objekt erstellen 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, was durch das Feld metadata: name angegeben wird. Das Service-Objekt ist auf eine App mit dem Namen nginx ausgerichtet, was durch labels.app: nginx und selector.app: nginx angegeben wird. Das Service-Objekt macht Port 80 verfügbar und nennt ihn web. Dieses Service-Objekt steuert die Netzwerkdomain und leitet den Internetverkehr 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 durch das Feld replicas: 3 festgelegt.
  • Die Vorlage Pod, die durch den Abschnitt .spec.template festgelegt wird, gibt an, dass ihre Pod-Objekte mit app: nginx gekennzeichnet sind.
  • Die Spezifikation Pod, die im Abschnitt .template.spec festgelegt ist, gibt an, dass die Pods von StatefulSet einen Container namens nginx ausführen, der wiederum das Image nginx mit Version 1.23 ausführt.
  • Die Pod-Spezifikation verwendet den vom Service-Objekt geöffneten Webport.
  • Im Bereich .template.spec.volumeMounts wird ein mountPath-Feld mit dem Namen www angegeben. 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 wird und verfügbar ist. Das StatefulSet ersetzt automatisch Pod-Objekte, die fehlerhaft sind oder aus ihren Knoten entfernt wurden, und ordnet den Speicherressourcen, Ressourcenanforderungen 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, sodass die zugrunde liegenden Volumes bei Bedarf erstellt werden. Anwendungen können mit einem PersistentVolumeClaim-Objekt nichtflüchtigen Speicher anfordern.

Normalerweise müssen Sie zusätzlich zum Pod-Objekt auch PersistentVolumeClaim-Objekte erstellen. StatefulSet-Objekte enthalten jedoch ein volumeClaimTemplates-Array, mit dem die PersistentVolumeClaim-Objekte generiert werden. Jedes StatefulSet-Replikat erhält ein eigenes PersistentVolumeClaim-Objekt.

Weitere Informationen finden Sie unter Containerspeicher konfigurieren.

Nächste Schritte