Pod-Platzierung

In Kubernetes werden neu erstellte und nicht geplante Pods automatisch auf Knoten geplant, die ihren Anforderungen entsprechen. Durch die Verwendung von Knotenaffinität, Taints und Toleranzen haben Sie mehr Kontrolle über die Knoten, für die Pods geplant werden.

Mit Knotenaffinität können Sie Regeln festlegen, die die Ausführung von Pods auf bestimmte beschriftete Knoten beschränken. Taints werden auf Knoten angewendet, damit diese Pods nicht akzeptieren, während Toleranzen auf Pods angewendet werden, damit diese Taints tolerieren. Weitere Informationen zu Knotenaffinität, Taints und Toleranzen im Allgemeinen finden Sie in der Dokumentation zu Kubernetes. Informationen zum Anwenden von Knotenaffinität und Toleranzen auf Pods in ArcGIS Enterprise on Kubernetes finden Sie unter Verwalten von Pod-Platzierungen.

Die Kombination aus Knotenaffinität, Taints und Toleranzen ermöglicht eine granulare Steuerung der Arbeitslast-Platzierung, um die Isolation zu verbessern, die Ressourcenzuweisung zu optimieren und den Compliance-Anforderungen innerhalb des Kubernetes-Clusters effektiv gerecht zu werden:

• Isolieren von Arbeitslasten mit spezialisierten Anforderungen: Verwenden Sie Beschriftungen und Knotenaffinitätsregeln, um sicherzustellen, dass bestimmte Pods auf dedizierten Knoten geplant werden. Verwenden Sie Taints, um Knoten mit bestimmten Eigenschaften, z. B. hohen CPU- oder Speicheranforderungen, als dedizierte Knoten für ArcGIS-Arbeitslasten zu markieren. Wenden Sie Toleranzen auf Service-Pods an, um sicherzustellen, dass sie auf Knoten mit den erforderlichen Ressourcen geplant werden.
• Optimieren der Ressourcenzuweisung: Wenden Sie Taints auf Knoten mit begrenzten Ressourcen an, um eine Überlastung der Ressourcen zu verhindern, und definieren Sie Toleranzen für Service-Pods, die den Ressourcenbeschränkungen auf diesen Knoten entsprechen. Kombinieren Sie Knotenaffinität mit Taints und Toleranzen, um sicherzustellen, dass Service-Pods nur auf Knoten geplant werden, die den entsprechenden Ressourcenanforderungen gerecht werden.
• Auf Geolokalisierung basierende Planung: Für Anwendungen, die Datenlokalität oder die Einhaltung spezifischer Bestimmungen erfordern, verwenden Sie Knotenaffinität, um Service-Pods basierend auf der geographischen Position von Knoten zu planen. Wenden Sie Taints basierend auf der physischen Position von Knoten oder basierend auf Bestimmungen zur Datenhoheit an, und wenden Sie Toleranzen auf Service-Pods an, um sicherzustellen, dass sie auf Knoten geplant werden und mit den erforderlichen Positionsbeschränkungen kompatibel sind.

Automatische Skalierung verbessert die Verwendung von Knotenaffinität und Toleranzen, indem die Anzahl der Pods dynamisch an die Arbeitslastanforderungen angepasst wird. Durch diese dynamische Skalierung wird sichergestellt, dass Pods effizient auf Knoten geplant werden, die bestimmte Anforderungen erfüllen oder über die erforderlichen Ressourcen verfügen, wodurch die Ressourcenzuweisung optimiert wird. Durch Kombination von automatischer Skalierung mit Knotenaffinität und -toleranzen kann für Kubernetes-Cluster eine bessere Ressourcenauslastung, Performance und Skalierbarkeit erreicht werden. Dies ermöglicht die Anpassung an schwankende Arbeitslasten unter Einhaltung von Knotenbeschränkungen und -präferenzen. Weitere Informationen zur automatischen Skalierung finden Sie unter Service-Skalierung.

Szenarien

Die folgenden Szenarien veranschaulichen, wie Ihre Organisation von der Verwaltung der Pod-Platzierung für Services profitieren kann.

Szenario 1: Saisonaler Anstieg des Datenverkehrs bei öffentlichen Kartenerstellungsservices

Eine öffentliche Organisation verzeichnet während eines örtlichen Festivals eine erhebliche Zunahme des Datenverkehrs. Beim Zugriff auf die Webkarte mit Informationen zur Veranstaltung kommt es zu Verzögerungen durch die hohe Nachfrage beim zugrunde liegenden Kartenservice. Um dieser Situation gerecht zu werden, geht der Organsiationsadministrator folgendermaßen vor:

• Er konfiguriert Knoten mit hohen CPU- und Speicherressourcen mit dem Schlüssel/Wert-Paar high-performance: true.
• Er wendet Knotenaffinitätsregeln an, um sicherzustellen, dass die Kartenservice-Pods auf Knoten mit hohen CPU- und Speicherressourcen geplant werden:
  • Typ: Bevorzugt
  • Schlüssel: high-performance
  • Operator: Ist vorhanden
  • Wert: true

• Er wendet Toleranzen an, um die Ausführung von Pods auf Knoten zu ermöglichen, auf die Taints für Arbeitslasten mit hoher Performance angewendet wurden, und stellt so sicher, dass der Kartenservice dem Anstieg des Datenverkehrs gerecht werden kann:
  • Effekt: NoSchedule
  • Schlüssel: workload
  • Operator: Gleich
  • Wert: high-performance
• Er wendet Taints mit workload=high-performance:NoSchedule auf Knoten mit hoher Performance an.

Szenario 2: Datenverarbeitung für die Umweltüberwachung

Eine Umweltbehörde führt eine Reihe von räumlichen Analysen durch, um Änderungen bei der Flächennutzung zu überwachen. Die Analyse erfordert beträchtliche Rechenressourcen, und die Behörde hat zu diesem Zweck dedizierte Knoten mit GPUs bereitgestellt. Um sicherzustellen, dass die räumliche Analyse effektiv ausgeführt wird, ohne mit anderen Services um Ressourcen zu konkurrieren, geht der Organisationsadministrator folgendermaßen vor:

• Er konfiguriert GPU-fähige Knoten mit dem Schlüssel/Wert-Paar gpu: true.
• Er wendet Knotenaffinitätsregeln an, um die Analyse-Pods auf den GPU-Knoten zu planen:
  • Typ: Erforderlich
  • Schlüssel: gpu
  • Operator: In
  • Wert: true
• Er wendet Toleranzen an, um die Ausführung von Pods auf den GPU-Knoten mit Taints zuzulassen:
  • Effekt: NoSchedule
  • Schlüssel: workload
  • Operator: Gleich
  • Wert: high-resource
• Er wendet Taints auf GPU-Knoten mit workload=high-resource:NoSchedule an, um zu verhindern, dass weniger ressourcenintensive Pods dort geplant werden.

Szenario 3: Ressourcenoptimierung für freigegebene Feature-Services

Die GIS-Abteilung einer Stadt verfügt über zahlreiche Feature-Services, die zwar nicht intensiv genutzt werden, aber insgesamt eine einzelne Service-Bereitstellung belasten. Damit die Abteilung die Service-Verfügbarkeit aufrechterhalten kann, ohne das System zu überlasten, geht der Organisationsadministrator folgendermaßen vor:

• Er konfiguriert Knoten mit dem Schlüssel resource-constrained.
• Er wendet Knotenaffinitätsregeln an, um die Planung für Knoten mit geringerer Ressourcenverfügbarkeit zu priorisieren:
  • Typ: Bevorzugt
  • Schlüssel: resource-constrained
  • Operator: DoesNotExist
• Er wendet Toleranzen auf Feature-Service-Pods an, um sicherzustellen, dass diese trotz der Beschränkungen auf Knoten mit Taints geplant werden können:
  • Effekt: PreferNoSchedule
  • Schlüssel: resource-constrained
  • Operator: Ist vorhanden
• Er wendet mit resource-constrained:PreferNoSchedule Taints auf Knoten mit Ressourceneinschränkungen an.

Szenario 4: Vermeidung von Unterbrechungen des Data Store während der Cluster-Skalierung

Eine Regierungsbehörde verzeichnet ein Service-Nutzungsmuster, bei dem Services tagsüber intensiv genutzt werden. Für dieses Muster ist eine große Anzahl von Cluster-Knoten erforderlich, um alle für diese Services benötigten Pod-Replikate zu unterstützen. Da die Services nachts nicht genutzt werden, möchte die Organisation die Anzahl der Knoten reduzieren, um die Cloud-Computing-Kosten zu senken. Das Beenden von Knoten, auf denen systemverwaltete Data-Store-Pods ausgeführt werden, birgt jedoch das Risiko einer Unterbrechung dieser Pods. Um eine solche potenzielle Unterbrechung zu verhindern, geht der Organisationsadministrator folgendermaßen vor:

• Er erstellt eine separate Knotengruppe für Data-Store-Pods, wobei jeder Knoten mit dem Schlüssel-Wert-Paar data-store: true beschriftet ist.
• Er wendet Knotenaffinitätsregeln an, um sicherzustellen, dass Data-Store-Pods für Knoten in dieser Gruppe geplant werden.
  • Typ: Erforderlich
  • Schlüssel: data-store
  • Operator: In
  • Wert: true
• Er wendet Toleranzen an, um die Ausführung von Data-Store-Pods auf den Data-Store-Knoten mit Taints zuzulassen:
  • Effekt: NoSchedule
  • Schlüssel: workload
  • Operator: Gleich
  • Wert: data-store
• Er wendet Data-Store-Taints mit workload=data-store:NoSchedule an.
• Er skaliert die Data-Store-Knotengruppe nicht herunter, wenn nachts die Clusterknoten herunterskaliert werden.