Veröffentlicht am: May 7, 2021
Heute führen wir Amazon EMR on Amazon EKS-Support für Pod-Vorlagen ein, um die Ausführung von Spark-Aufträgen auf gemeinsam genutzten EKS-Clustern zu vereinfachen. Ein Pod ist eine Gruppe von einem oder mehreren Containern mit gemeinsam genutzten Speicher- und Netzwerkressourcen und einer Spezifikation, wie die Container ausgeführt werden sollen. Pod-Vorlagen sind Spezifikationen, die festlegen, wie jeder Pod läuft. Kunden konsolidieren oft mehrere Anwendungen auf einem gemeinsamen EKS-Cluster, um die Auslastung zu verbessern und Kosten zu sparen. Jede Anwendung kann jedoch unterschiedliche Anforderungen haben. Beispielsweise können Sie leistungsintensive Arbeitslasten wie ML-Modell-Trainingsaufträge auf SSD-gestützten Instances für eine bessere Leistung oder Ad-hoc-Arbeitslasten auf Spot-Instances für geringere Kosten ausführen. Sie können auch einen separaten Zeitplan für die Protokollweiterleitung an Ihre bestehende Anwendung zur Überwachung erstellen. Mit dieser Version können Sie Pod-Vorlagen mit EMR auf EKS verwenden, um zu konfigurieren, wie Spark-Aufträge auf gemeinsam genutzten EKS-Clustern ausgeführt werden.
Zur Kostensenkung können Kunden Zeitpläne für die Ausführung von Spark-Treiber-Pods auf EC2 On-Demand-Instances und für die Ausführung von Spark-Executor-Pods auf EC2 Spot-Instances erstellen. Kubernetes-Kunden verwenden häufig Taints, Toleranzen und Labels, um sicherzustellen, dass Pods auf den richtigen Worker Nodes eingeplant werden. Ein Taint ist eine Eigenschaft eines Worker Nodes, die es ihm ermöglicht, einzuschränken, welche Pods auf ihm ausgeführt werden können. Umgekehrt ermöglicht eine Duldung die Zeitplanung eines Pods über einen passenden Taint. Das Label wird mit nodeSelectors verwendet, um den Pod zum Worker zu leiten. Jetzt können Pod-Templates verwendet werden, um Toleranzen auf den Spark-Treiber-Pod anzuwenden, damit er auf einer EC2 On-Demand-Instance ausgeführt wird, und eine separate Toleranz für den Spark-Executor-Pod, damit sie nur auf EC2 Spot-Instances ausgeführt werden.
Zur Weiterleitung von Protokollen an Ihre zentralisierte Protokollierungsanwendung können Kunden einen Sidecar-Container mit ihrem Spark-Auftrag bereitstellen. Ein Sidecar-Container wird im selben Pod wie der Anwendungscontainer bereitgestellt, bietet aber zusätzliche Funktionen. In diesem Fall leitet es Auftragsprotokolle weiter. EMR auf EKS bietet eine integrierte Protokollweiterleitung an Amazon CloudWatch und Amazon S3. Wenn ein Kunde jedoch Protokolle an seine eigene Anwendung zur Protokollierung weiterleiten möchte, würde er eine Protokollweiterleitung als Daemonset einsetzen. Daemonsets werden direkt auf den Kubernetes-Worker-Nodes ausgeführt. Jetzt können Pod-Templates verwendet werden, um die Protokollweiterleitung als Sidecar-Container pro Auftrag oder pro Pod einzusetzen.
Um die Ressourcenauslastung zu erhöhen, können Kunden mehrere Teams unterstützen, die ihre Workloads auf demselben EKS-Cluster ausführen. Häufig erhält jedes Team eine bestimmte EC2-Nodegroup, auf der es seine Workloads ausführen kann. Zuvor konnten Workloads nur mithilfe von Labels und Affinität an die richtige Nodegroup geleitet werden. Kunden können Taints auf die Nodegroup eines Teams anwenden und jetzt Pod-Templates verwenden, um eine entsprechende Duldung auf ihre Workload anzuwenden. Dadurch wird sichergestellt, dass nur das benannte Team Aufträge für seine Nodegroup planen kann.
Um eine teambasierte Nodegroup zu implementieren, beginnen Sie mit der Erstellung einer Nodegroup, die ein Label und einen Taint enthält, der das Team repräsentiert. Ein Taint ist eine Eigenschaft eines Worker Nodes, die es ihm ermöglicht, einzuschränken, welche Pods auf ihm ausgeführt werden können. Umgekehrt ermöglicht eine Duldung die Zeitplanung eines Pods über einen passenden Taint. Das Label leitet die Anwendung mit Hilfe der Affinität zur designierten Nodegroup des Teams und eine Toleranz ermöglicht es, den Zeitplan über den Taint laufen zu lassen. Erstellen Sie eine Pod-Vorlage, die die entsprechende Tolerierung und Affinität enthält, und speichern Sie sie in einem S3-Bucket, auf den Ihr Auftrag zugreifen kann. Pod-Templates können für den Spark-Treiber und die Ausführungs-Pods erstellt werden, um verschiedene Bereitstellungsoptionen bereitzustellen, und Sie geben den Speicherort der Vorlagen während der Übermittlung der Aufträge an.
Weitere Informationen zu den Funktionen und Anwendungsfällen von Pod-Vorlagen finden Sie in unserer Dokumentation. Weitere Informationen zu Amazon EMR on EKS finden Sie in unserer Amazon EMR on EKS Dokumentation oder in unserem Deep-Dive Tech Talk zu Amazon EMR on EKS.