Zustandsorientierte Arbeitslasten erstellen

Auf dieser Seite wird erläutert, wie Sie zustandsorientierte Arbeitslasten in einem GDC-Kubernetes-Cluster (Google Distributed Cloud) ohne Internetverbindung erstellen und verwalten. Mit zustandsorientierten Arbeitslasten können Sie die Bereitstellung 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.

Diese Seite richtet sich an Entwickler in der Gruppe der Anwendungsbetreiber, die für die Erstellung von Anwendungsarbeitslasten für ihre Organisation verantwortlich sind. Weitere Informationen finden Sie in der Dokumentation zu Zielgruppen für GDC-Air-Gap-Umgebungen.

Hinweise

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

  1. Suchen Sie den Namen des Kubernetes-Clusters oder fragen Sie Ihren Plattformadministrator danach.

  2. Melden Sie sich an und generieren Sie die kubeconfig-Datei für den Kubernetes-Cluster, falls Sie noch keine haben.

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

Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Namespace Admin“ (namespace-admin) in Ihrem Projekt-Namespace zuzuweisen, um die erforderlichen Berechtigungen zum Erstellen zustandsorientierter Workloads zu erhalten.

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.

So erstellen Sie eine StatefulSet- und eine Service-Ressource:

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 Projekt-Namespace, in dem die Container-Arbeitslasten bereitgestellt werden sollen.

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

  • APP_NAME: Der Name der Anwendung, die in der Bereitstellung ausgeführt werden soll.

  • APP_LABEL_NAME: Die Labelauswahl, die bestimmt, welche Pods zum Objekt StatefulSet 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 ist 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.

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

Im folgenden Beispiel werden mit dem StatefulSet-Objekt und dem entsprechenden Service-Objekt zustandsorientierte Containerarbeitslasten erstellt:

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. Dies wird vom Feld metadata: name angegeben. Das Service-Objekt zielt auf eine App namens nginx ab, wie durch labels.app: nginx und selector.app: nginx angegeben. Das Service-Objekt gibt den Port 80 frei und gibt ihm den Namen 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 Vorlage Pod, die durch den Abschnitt .spec.template festgelegt wird, gibt an, dass die zugehörigen Pod-Objekte mit dem Label app: nginx gekennzeichnet sind.
  • Die Spezifikation Pod, die im Abschnitt .template.spec festgelegt ist, gibt an, dass die Pods von StatefulSet einen Container (nginx) ausführen. Dieser führt das Image nginx in der Version 1.23 aus.
  • Die Pod-Spezifikation verwendet den vom Service-Objekt geöffneten Webport.
  • Im Abschnitt .template.spec.volumeMounts wird ein mountPath-Feld mit dem Namen www angegeben. Der 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 Speicher bereit.

Nach dem Erstellen sorgt das StatefulSet dafür, dass die gewünschte Anzahl von Pod-Objekten ausgeführt wird und jederzeit 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, sodass die zugrunde liegenden Volumes nach Bedarf erstellt werden. Anwendungen können nichtflüchtigen Speicher mit einem PersistentVolumeClaim-Objekt anfordern.

Normalerweise müssen Sie zusätzlich zur Erstellung des Pod-Objekts auch PersistentVolumeClaim-Objekte erstellen. StatefulSet-Objekte enthalten jedoch ein volumeClaimTemplates-Array, das die PersistentVolumeClaim-Objekte generiert. Jedes StatefulSet-Replikat erhält sein eigenes PersistentVolumeClaim-Objekt.

Weitere Informationen finden Sie unter Containerspeicher konfigurieren.