---
sourceDocument: Yokohama Now Platform-Fähigkeiten
sourceDocumentLink: https://www.servicenow.com/docs/r/de-DE/yokohama/servicenow-platform

 Release :

    - yokohama

ft:locale :

    - de-DE

ft:publication_title :

    - Yokohama Now Platform-Fähigkeiten

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Containerisierte automatische Skalierung des MID-Servers

# Containerisierte automatische Skalierung des MID-Servers {#ariaid-title1}

* Freigeben Version: Yokohama
* 
* Aktualisiert 30. Januar 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 Minuten Lesedauer

MID-Server können über Stateful Set mit einer beliebigen Anzahl von Replikaten bereitgestellt werden. Sie können automatisch skalieren, indem sie den automatischen Skalierer für horizontale Kubernetes-Pods (HPA) nutzen. Die automatische Skalierung des horizontalen Pods aktualisiert automatisch eine Arbeitsauslastungsressource (z. B. eine Bereitstellung oder ein Stateful Set), um den Bedarf anzupassen.

|-|
|   |
[ ]

{#containerized-mid-autoscaling__table_p53_ms4_nhb} Kubernetes kann eine beliebige Anzahl von zustandsbehafteten MID-Server-Replikaten hinzufügen oder entfernen, je nachdem, welche Arbeitsauslastung erforderlich ist. HPA unterstützt nur CPU- und Arbeitsspeichermetriken. MID-Server können als statusbehaftete Anwendung bereitgestellt werden, indem die folgenden Informationen im Abschnitt „Stateful Set" des Bereitstellungsanforderungsformulars angegeben werden:

* Name
* Headless-Servicename
* Anspruch auf persistentes Volumen (PVC)
* Parameter, z. B. Speicherklasse, Zugriffsmodi und Speicheranforderung
* Die Ressourcenanforderung/-Grenzwert
{#containerized-mid-autoscaling__ul_vv1_bcz_2wb}

Das PVC deklariert das gewünschte persistente Volume, auf dem der MID-Server config.xml, Metadaten-Dateien und mehrere seiner Unterordner speichert.

Während Arbeitsauslastungsschwankungen kann ein Pod mit einem laufenden MID-Server-Container entfernt und durch einen neuen ersetzt werden. Stateful Set stellt sicher, dass dasselbe persistente Volume an den neuen Pod angehängt wird, wodurch der MID-Server seinen Status fortsetzen kann.

Die einzigen Unterordner, die auf dem persistenten Volume bereitgestellt werden können, sind diejenigen, die bei einer neuen MID-Server-Installation anfänglich leer sind. Die config.xml Datei- und andere Metadatendateien müssen gesichert werden, wenn der Pod während des Starts heruntergefahren und wiederhergestellt wird.

Bereitstellungsanforderungen, die als YAML-Dateien exportiert werden, können verwendet werden, um eine Stateful Set-Arbeitsauslastung und neue MID-Server-Pods im Kubernetes-Cluster zu erstellen.

Wenn Sie Änderungen an der Bereitstellungs-YAML-Datei vornehmen und sie erneut anwenden, werden die vorhandenen Pods der Bereitstellung neu erstellt. Bei der Bereitstellung von Stateful Set werden die Konfigurationsdateien aus dem Sicherungsordner wiederhergestellt. Das init-Skript muss die Änderungen der Bereitstellungsumgebung erkennen und auf die Konfigurationsdateien anwenden, bevor der MID-Server gestartet wird.

## Aktivierung der automatischen HPA-Skalierung {#containerized-mid-autoscaling__section_g45_r2z_2wb}

Die automatische HPA-Skalierung kann für jede vorhandene Stateful Set-Arbeitsauslastung aktiviert werden, indem ein HPA-Controller erstellt wird.

Wenn Sie eine Bereitstellungsanforderung erstellen, können Sie entweder HPA-Version 1 oder Version 2 auswählen.

Wenn Sie eine Bereitstellungsanforderung auf der Instanz mit einer HPA-Konfiguration erstellen, wenden Sie die exportierte YAML-Datei an, und die automatische HPA-Skalierung funktioniert sofort.