Richtlinien für Verkäufer von Containerprodukten Sicherheitsrichtlinien Anforderungen bezüglich Kundeninformationen Anforderungen an die Produktnutzung Architekturanforderungen Anforderungen an die Struktur des Helm-Diagramms Anweisungen zur Verwendung des Container-Produkts Anforderungen für Amazon EKS-Zusatzprodukte

Container-based Produktanforderungen für AWS Marketplace

AWS Marketplace erfüllt die folgenden Anforderungen für alle containerbasierten Produkte und Angebote auf. AWS Marketplace Diese Anforderungen tragen dazu bei, unseren Kunden einen sicheren und vertrauenswürdigen Katalog zu bieten. Wir empfehlen Verkäufern außerdem, die Implementierung zusätzlicher Kontrollen und Protokolle zu überprüfen, sofern diese den Anforderungen ihrer spezifischen Produkte entsprechen.

Alle Produkte und die zugehörigen Metadaten werden bei der Einreichung überprüft, um sicherzustellen, dass sie die aktuellen AWS Marketplace Richtlinien erfüllen oder übertreffen. Diese Richtlinien werden regelmäßig aktualisiert, um sie an die sich ändernden Sicherheitsrichtlinien anzupassen. AWS Marketplace scannt kontinuierlich Produkte, um sicherzustellen, dass bestehende Angebote auch weiterhin alle Änderungen dieser Anforderungen erfüllen. Wenn ein Produkt nicht den Anforderungen entspricht, AWS Marketplace wird der Verkäufer kontaktiert, um sein Produkt auf den neuesten Stand zu bringen, damit es den neuen Standards entspricht. In einigen Fällen kann es vorkommen, dass Produkte für neue Abonnenten vorübergehend nicht verfügbar sind, bis die Probleme behoben sind. Dieser Prozess trägt dazu bei, die Sicherheit und Vertrauenswürdigkeit der AWS Marketplace Plattform für alle Benutzer aufrechtzuerhalten.

Themen

Richtlinien für Verkäufer von Containerprodukten
Sicherheitsrichtlinien
Anforderungen bezüglich Kundeninformationen
Anforderungen an die Produktnutzung
Architekturanforderungen
Anforderungen an die Struktur des Helm-Diagramms
Anweisungen zur Verwendung des Container-Produkts
Anforderungen für Amazon EKS-Zusatzprodukte

Richtlinien für Verkäufer von Containerprodukten

Als Verkäufer von Containerprodukten müssen Sie die folgenden Richtlinien einhalten:

Standardmäßig sind Sie auf maximal 20 öffentliche Angebote für Container-Produkte beschränkt. Wenn Sie Ihr Limit überschreiten, wird Ihr Konto regelmäßig einer Leistungsüberprüfung unterzogen, und Sie müssen möglicherweise Angebote einschränken, die unterdurchschnittlich abschneiden. Wir gewähren oder widerrufen Erhöhungen dieses Limits nach unserem alleinigen Ermessen.

Sicherheitsrichtlinien

Alle Produkte auf Containerbasis müssen die folgenden Sicherheitsanforderungen erfüllen:

Container-Images dürfen keine bekannten Sicherheitslücken, Malware oder End-of-Life (EoL-) Softwarepakete und Betriebssysteme enthalten.
Container dürfen keine AWS Anmeldeinformationen für den Zugriff auf AWS Dienste anfordern. Wenn Ihr Produkt auf AWS Dienste zugreifen muss, müssen Sie eine der folgenden Optionen verwenden:
- IAM-Rollen für Dienstkonten für Amazon Elastic Kubernetes Service (Amazon EKS) -Workloads.
- IAM-Rollen für Aufgaben, für Amazon Elastic Container Service (Amazon ECS) -Workloads.
Container-based Produkte müssen nur die geringsten Rechte benötigen, um ausgeführt zu werden. Weitere Informationen finden Sie unter Sicherheit in Amazon Elastic Container Service und Sicherheit in Amazon EKS.
Container-Images sollten so konfiguriert sein, dass sie standardmäßig mit Nicht-Root-Rechten ausgeführt werden.
Container dürfen keine fest codierten Geheimnisse wie Passwörter (auch nicht gehasht) für Systembenutzer und -dienste, private Schlüssel, Anmeldeinformationen usw. enthalten.
Die Authentifizierung in Diensten, die innerhalb des Containers ausgeführt werden, darf keine kennwortbasierte Authentifizierung verwenden, auch wenn das Passwort vom Benutzer beim Start generiert, zurückgesetzt oder definiert wird. Passwörter mit und ohne Angabe sind ebenfalls nicht zulässig.
Container-Images dürfen keine Ebenen mit nicht unterstützten Architekturen enthalten (z. B. integrierte Attestation Framework-Metadaten).

Anforderungen bezüglich Kundeninformationen

Alle containerbasierten Produkte müssen die folgenden Anforderungen an Kundeninformationen erfüllen:

Software darf ohne das Wissen und die ausdrückliche Zustimmung des Kunden keine Kundendaten sammeln oder exportieren, es sei denn, BYOL (Bring Your Own License) verlangt dies. Anwendungen, die Kundendaten sammeln oder exportieren, müssen den folgenden Richtlinien entsprechen:
- Die Erfassung der Kundendaten muss eigenständig, automatisiert und sicher erfolgen. Käufer müssen nicht darauf warten, dass die Verkäufer die Bereitstellung der Software genehmigen.
- Die Erfassung von Kundendaten muss mit Ihren Vereinbarungen AWS, einschließlich, aber nicht beschränkt auf, den AWS Marketplace-Geschäftsbedingungen, den AWS Servicebedingungen , der AWS Datenschutzerklärung und der AWS Kundenvereinbarung übereinstimmen.
- Zahlungsinformationen dürfen nicht erfasst werden.

Anforderungen an die Produktnutzung

Alle Produkte in Behältern müssen die folgenden Anforderungen an die Produktnutzung erfüllen:

Verkäufer können nur voll funktionsfähige Produkte anbieten. Beta- oder Vorabversionen von Produkten zu Test- oder Evaluierungszwecken sind nicht zulässig. Entwickler-, Community- und BYOL-Editionen kommerzieller Software werden unterstützt, wenn der Verkäufer AWS Marketplace innerhalb von 90 Tagen nach Bereitstellung der kostenlosen Version eine entsprechende kostenpflichtige Version bereitstellt.
Alle Anweisungen zur Verwendung eines containerbasierten Produkts müssen alle Schritte zur Bereitstellung containerbasierter Produkte enthalten. Die Nutzungsanweisungen müssen Befehle und Bereitstellungsressourcen enthalten, die auf die entsprechenden Container-Images verweisen. AWS Marketplace
Container-based Die Produkte müssen alle Container-Images enthalten, die ein Abonnent zur Verwendung der Software benötigt. Darüber hinaus darf es bei containerbasierten Produkten nicht erforderlich sein, dass ein Benutzer das Produkt mit Bildern von außen startet AWS Marketplace (z. B. Container-Images aus Repositorys von Drittanbietern).
Container und die dazugehörige Software müssen im Self-Service-Modus bereitgestellt werden können und dürfen keine zusätzlichen Zahlungsmethoden oder Kosten erfordern. Anwendungen, bei deren Bereitstellung externe Abhängigkeiten erforderlich sind, müssen die folgenden Richtlinien einhalten:
- Die Anforderung muss in der Beschreibung oder den Nutzungshinweisen der Liste angegeben werden. Für dieses Produkt ist beispielsweise eine Internetverbindung erforderlich, um ordnungsgemäß bereitgestellt zu werden. Die folgenden Pakete werden bei der Bereitstellung heruntergeladen:<list of package>.
- Verkäufer sind für die Nutzung und Gewährleistung der Verfügbarkeit und Sicherheit aller externen Abhängigkeiten verantwortlich.
- Wenn die externen Abhängigkeiten nicht mehr verfügbar sind, muss das Produkt AWS Marketplace ebenfalls entfernt werden.
- Für die externen Abhängigkeiten dürfen keine zusätzlichen Zahlungsmethoden oder Kosten erforderlich sein.
Container, die eine ständige Verbindung zu externen Ressourcen erfordern, die nicht der direkten Kontrolle des Käufers unterliegen — z. B. externe APIs oder die vom Verkäufer oder Dritten AWS-Services verwaltet werden — müssen die folgenden Richtlinien befolgen:
- Die Anforderung muss in der Beschreibung oder den Nutzungshinweisen des Angebots angegeben werden. Für dieses Produkt ist beispielsweise eine ständige Internetverbindung erforderlich. Die folgenden laufenden externen Dienste sind erforderlich, um ordnungsgemäß zu funktionieren:<list of resources>.
- Verkäufer sind für die Nutzung und Gewährleistung der Verfügbarkeit und Sicherheit aller externen Ressourcen verantwortlich.
- Wenn die externen Ressourcen nicht mehr verfügbar sind, muss das Produkt AWS Marketplace ebenfalls entfernt werden.
- Für die externen Ressourcen dürfen keine zusätzlichen Zahlungsmethoden oder Kosten erforderlich sein, und der Verbindungsaufbau muss automatisiert werden.
Produktsoftware und Metadaten dürfen keine Sprache enthalten, die Nutzer zu anderen Cloud-Plattformen, zusätzlichen Produkten oder Upsell-Services weiterleitet, auf AWS Marketplace denen sie nicht verfügbar sind.
Wenn es sich bei Ihrem Produkt um ein Zusatzprodukt zu einem anderen Produkt oder Produkt eines anderen ISV handelt, muss aus Ihrer Produktbeschreibung hervorgehen, dass es die Funktionalität des anderen Produkts erweitert und dass Ihr Produkt ohne dieses Produkt nur einen sehr begrenzten Nutzen hat. Beispielsweise erweitert dieses Produkt die Funktionalität von <product name>und ohne dieses Produkt ist dieses Produkt nur sehr eingeschränkt nutzbar. Bitte beachten Sie, dass <product name>für den vollen Funktionsumfang dieser Liste möglicherweise eine eigene Lizenz erforderlich ist.

Architekturanforderungen

Alle containerbasierten Produkte müssen die folgenden Architekturanforderungen erfüllen:

Die Quell-Container-Images für AWS Marketplace müssen in das Amazon Elastic Container Registry (Amazon ECR) -Repository übertragen werden, das Eigentum von ist. AWS Marketplace Sie können diese Repositorys AWS Marketplace Management Portal unter „Serverprodukte“ für jedes Ihrer Container-Produktangebote erstellen.
Container-Images müssen auf Linux basieren.
Kostenpflichtige containerbasierte Produkte müssen auf Amazon ECS, Amazon EKS oder bereitgestellt werden können. AWS Fargate
Bezahlte containerbasierte Produkte mit Vertragspreisen und einer Integration mit AWS License Manager sollten auf Amazon EKS, Amazon ECS, Amazon EKS Anywhere AWS Fargate, Amazon ECS Anywhere, Red Hat OpenShift Service on AWS (ROSA), selbstverwalteten Kubernetes-Clustern vor Ort oder in Amazon Elastic Compute Cloud bereitgestellt werden.
Bei Helm-Chart-Produkten müssen die Container-Image-Referenzen so strukturiert sein, dass sie eine regionsübergreifende Bereitstellung unterstützen. Anforderungen an die Struktur des Helm-Diagramms
Wenn Ihr containerbasiertes Produkt erfordert, dass der Käufer ein Amazon Machine Image (AMI) bereitstellt, muss es sich entweder um ein AWS verwaltetes AMI oder um ein separates AMI handeln, das in veröffentlicht wurde. AWS Marketplace Wenn Sie Ihr eigenes AMI in veröffentlichen AWS Marketplace, muss es den Anforderungen von entsprechen, AMI-based Produktanforderungen für AWS Marketplace und Sie müssen angeben, dass es sich um ein Zusatzprodukt handelt, wie in der gefordert. Richtlinien zur Produktnutzung Sie können den Preis für Ihr AMI-based Produkt mit BYOL angeben, da es sich dabei um eine Erweiterung Ihres Angebots auf Containerbasis handelt. AWS Marketplace scannt AMI-based Produkte nach ungepatchten häufigen Sicherheitslücken und Sicherheitsanforderungen (CVEs). Ihre Käufer müssen Ihr AMI-based Produkt außerdem abonnieren, bevor sie es anbieten können.

Anforderungen an die Struktur des Helm-Diagramms

Alle Helm-Chart-Produkte, die eingereicht wurden, AWS Marketplace müssen die folgenden Strukturanforderungen erfüllen, um eine korrekte Regionalisierung und den regionsübergreifenden AWS Einsatz zu gewährleisten:

Verweise auf Container-Images müssen ausschließlich in der values.yaml Datei definiert werden und dürfen nicht in anderen Dateien innerhalb des Helm-Diagramms fest codiert werden. Dadurch können AWS Marketplace diese Referenzen automatisch ersetzt werden, wenn Sie Ihr Produkt in verschiedenen Regionen replizieren.
Die values.yaml Datei muss Variablen für alle Container-Image-Referenzen verwenden.
Optional können Sie einzelne Felder auf derselben Ebene wie das Repository aufteilen registry und tag in separate Felder unterteilen, um Ihre Bildreferenz aufzubauen.
Helm-Vorlagen müssen diese Variablen mithilfe der standardmäßigen Helm-Vorlagensyntax referenzieren (z. B.{{ .Values.image.repository }}:{{ .Values.image.tag }}).
Vermeiden Sie die Verwendung bedingter Logik in Vorlagen, die die in values.yaml definierten Bildreferenzen umgehen würde.
Wenn Sie Ihr Helm-Diagramm mit verschiedenen AWS Regionen testen, stellen Sie sicher, dass bei einer Änderung der Region alle Bildreferenzen in den bereitgestellten Ressourcen values.yaml korrekt aktualisiert werden.

AWS Marketplace überprüft, ob alle Container-Image-Referenzen in der values.yaml Datei während des Produkteinreichungsprozesses korrekt definiert sind. Produkte, die diese Anforderungen nicht erfüllen, werden abgelehnt.

Anforderungen für Verweise auf Container-Images in Helm-Diagrammen

Im Folgenden werden Ansätze zur Strukturierung von Container-Bildreferenzen in Helm-Diagrammen veranschaulicht:

values.yaml(empfohlenes Format):


image:
  registry: "709825985650.dkr.ecr.us-east-1.amazonaws.com"
  repository: "accuknox/kubearmor"
  tag: "v1.1.1"

Anmerkung

Wir empfehlen den oben genannten Ansatz für Ihre Strukturvalues.yaml, aber die folgenden alternativen Methoden sind ebenfalls gültig.

values.yaml(alternatives Format):


image:
  repository: "709825985650.dkr.ecr.us-east-1.amazonaws.com/guance/datakit"
  tag: "1.0"

values.yaml(alternatives Format):


image:
  repository: "709825985650.dkr.ecr.us-east-1.amazonaws.com/guance/datakit:1.0"

Anmerkung

Für die Bereitstellungsvorlage ist das unten stehende Format das einzig gültige verfügbare Format.

Vorlage für die Bereitstellung:


containers:
- name: kubearmor
  image: "{{ .Values.image.registry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}"

Falscher Ansatz (nicht verwenden):


containers:
- name: kubearmor
  image: "709825985650.dkr.ecr.us-east-1.amazonaws.com/accuknox/kubearmor:v1.1.1"

Mögliche Fehler bei der Validierung des Helm-Diagramms

AWS Marketplace Führt während des Produkteinreichungsprozesses Validierungsprüfungen für Helm-Chart-Produkte durch, um sicherzustellen, dass die Referenzanforderungen für Containerbilder eingehalten werden. Wenn Ihr Helm-Diagramm diese Anforderungen nicht erfüllt, können die folgenden Validierungsfehler auftreten:

Fehler	Erklärung
`INCOMPATIBLE_HELM_OBJECTS`	Die angegebenen Helm-Objekte werden für EKS-Add-Ons nicht unterstützt. Siehe Anforderungen für Amazon EKS-Zusatzprodukte.
`INVALID_DEPENDENT_HELM_CHARTS`	Abhängige Helm-Diagramme müssen im übergeordneten Diagrammverzeichnis enthalten sein und dürfen nicht aus externen Quellen stammen.
`INVALID_HELM_SENSITIVE_CONFIG`	Das Konfigurationsschema darf keine Felder enthalten, die vertrauliche Informationen sammeln. Konfigurationsschemas dürfen keine Passwörter, API-Schlüssel, Zertifikate oder Geheimnisse akzeptieren. Stellen Sie stattdessen Felder für geheime Kubernetes-Namen bereit, die Kunden separat erstellen.
`INVALID_HELM_CHART_IMAGES`	Alle Images, einschließlich Open-Source-Abhängigkeiten, müssen in AWS Marketplace Amazon ECR-Repositorys übertragen werden, die über die Anfrage zum Hinzufügen eines Repositorys erstellt wurden. Schritt 1: Repositorys hinzufügen
`INVALID_HELM_UNDECLARED_IMAGES`	Alle Verweise auf Container-Images müssen in der Anfrage „Version hinzufügen“ explizit aufgeführt werden.
`INVALID_HELM_LINT`	Die `helm lint` Überprüfung des Helm-Diagramms ist fehlgeschlagen. `helm lint`Lokal ausführen, um strukturelle oder syntaktische Probleme zu identifizieren und zu beheben. Verwenden Sie die Helm-Version `3.19.0` oder höher.
`INVALID_HELM_TEMPLATE`	Die `helm template` Überprüfung des Helm-Diagramms ist fehlgeschlagen. Das Diagramm kann nicht in gültige Kubernetes-Manifeste gerendert werden. Testen Sie lokal mit`helm template`, um Syntax- oder Logikfehler in der Vorlage zu identifizieren. Verwenden Sie die Helm-Version `3.19.0` oder höher.
`MISSING_HELM_DEPLOYMENT_CONFIG`	Das Helm-Diagramm für ein Amazon EKS-Add-on muss eine Bereitstellung oder DaemonSet Ressource enthalten. Amazon EKS benötigt mindestens einen dieser Workload-Typen für das Add-On-Lifecycle-Management. Siehe Anforderungen für Amazon EKS-Zusatzprodukte.
`INCOMPATIBLE_CONFIGURATION_SCHEMA_VERSION`	Die JSON-Schemaversion in `aws_mp_configuration_schema.json` wird nicht unterstützt. Informationen Schema-Anforderungen zu unterstützten Schemaversionen finden Sie unter.
`INVALID_IMAGE_REFERENCE`	Alle Bilder müssen als Variablen definiert `values.yaml` und mithilfe der Helm-Vorlagensyntax referenziert werden, wie unter beschriebenAnforderungen an die Struktur des Helm-Diagramms.
`MISSING_VALUES_IMAGE_REFERENCE`	Jede Container-Image-Referenz muss einen entsprechenden Eintrag in enthalten`values.yaml`.
`MISSING_IMAGE_TAG`	Verweise auf Containerbilder in `values.yaml` müssen explizite Tag-Werte enthalten oder standardmäßig die Diagrammversion von verwenden`Chart.yaml`.

Anweisungen zur Verwendung des Container-Produkts

Folgen Sie bei der Erstellung von Gebrauchsanweisungen für Ihr Behälterprodukt den Schritten und Anleitungen unterErstellung von Anweisungen zur Verwendung von AMI- und Container-Produkten für AWS Marketplace.

Anweisungen zur Verwendung des Helm-Diagramms

Bei der Erstellung von Gebrauchsanweisungen für Helm Chart-Produkte:

Dokumentieren Sie übersichtlich alle konfigurierbaren Parameter in Ihrer values.yaml Datei, einschließlich der Image-Repository-, Tag- und Registrierungsparameter.
Geben Sie Beispiele an, wie Sie diese Parameter bei der Installation des Helm-Diagramms überschreiben können.
Weisen Sie die Benutzer nicht an, bei der Installation des Charts andere Dateien zu ändern values.yaml oder --set Parameter zu verwenden.
Geben Sie Informationen darüber an, wie Ihr Produkt mit der Regionalisierung von Containerbildern umgeht.

Anforderungen für Amazon EKS-Zusatzprodukte

Ein Amazon EKS-Add-on ist eine Software, die Betriebsfunktionen Kubernetes für Anwendungen bereitstellt, aber nicht anwendungsspezifisch ist. Ein Amazon EKS-Add-on umfasst beispielsweise Observability-Agenten oder Kubernetes -Treiber, die es dem Cluster ermöglichen, mit den zugrunde liegenden AWS Ressourcen für Netzwerk, Datenverarbeitung und Speicherung zu interagieren.

Als Verkäufer von Containerprodukten können Sie zwischen verschiedenen Bereitstellungsoptionen wählen, einschließlich Amazon EKS. Sie können eine Version Ihres Produkts als AWS Marketplace Add-on im Amazon EKS-Zusatzkatalog veröffentlichen. Ihr Add-on wird in der Amazon EKS-Konsole neben den Add-Ons angezeigt, die von AWS anderen Anbietern verwaltet werden. Ihre Käufer können Ihre Software genauso einfach als Add-On bereitstellen wie die anderen Add-Ons.

Weitere Informationen finden Sie unter Erweiterungen für Amazon EKS im Amazon-EKS-Benutzerhandbuch.

Vorbereitung Ihres Containerprodukts als AWS Marketplace Add-on

Um Ihr Containerprodukt als AWS Marketplace Add-on zu veröffentlichen, muss es die folgenden Anforderungen erfüllen:

Ihr Container-Produkt muss in veröffentlicht werden AWS Marketplace.
Ihr Container-Produkt muss sowohl für AMD64- als auch für ARM64-Architekturen kompatibel gebaut werden.
Ihr Containerprodukt darf nicht das BYOL-Preismodell (Bring Your Own License) verwenden. https://docs.aws.amazon.com/marketplace/latest/userguide/pricing-container-products.html

Anmerkung
BYOL wird für die Lieferung von Amazon EKS-Add-Ons nicht unterstützt.
Sie müssen alle containerbasierten Produktanforderungen einhalten, einschließlich der Übertragung aller Container-Bilder und Helm -Diagramme in AWS Marketplace verwaltete Amazon ECR-Repositorys. Diese Anforderung umfasst beispielsweise Open-Source-Bilder. nginx Bilder und Diagramme können nicht in anderen externen Repositorys gehostet werden, einschließlich, aber nicht beschränkt auf Amazon ECR Public Gallery, undDocker Hub. Quay
HelmDiagramme — Bereiten Sie Ihre Software als Diagramm vor und verpacken Sie sie. Helm Das Amazon EKS-Add-on-Framework konvertiert ein Helm Diagramm in ein Kubernetes-Manifest. Einige Helm Funktionen werden in Amazon EKS-Systemen nicht unterstützt. In der folgenden Liste werden die Anforderungen beschrieben, die erfüllt sein müssen, bevor Sie Ihre Software als Amazon EKS-Add-on integrieren können. In dieser Liste verwenden alle Helm Befehle Helm Version 3.19.0:
- Alle Capabilities Objekte werden unterstützt, mit einer Ausnahme für. .APIVersions .APIVersionswird für nicht integrierte benutzerdefinierte Kubernetes APIs nicht unterstützt.
- Nur die Release.Namespace Objekte Release.Name und werden unterstützt.
- HelmHooks und die lookup Funktion werden nicht unterstützt.
- Alle abhängigen Diagramme müssen sich innerhalb des Helm Hauptdiagramms befinden (angegeben mit dem Repository-Pfad file://...).
- Das Helm Diagramm muss Helm Lint und Helm Template erfolgreich und ohne Fehler bestehen. Die Befehle lauten wie folgt:
  - HelmLint — helm lint helm-chart
    
    Zu den häufigsten Problemen gehören nicht deklarierte Diagramme in den Metadaten des übergeordneten Diagramms. Beispiel: chart metadata is missing these dependencies: chart-base Error: 1 chart(s) linted, 1 chart(s) failed
  - HelmVorlage — helm template chart-name chart-location --set k8version=Kubernetes-version --kube-version Kubernetes-version --namespace addon-namespace --include-crds --no-hooks -f any-overriden-values
    
    Übergeben Sie alle überschriebenen Konfigurationen mit dem -f Flag.
- Speichern Sie alle Container-Binärdateien in AWS Marketplace Amazon ECR-Repos. Verwenden Sie den zuvor gezeigten Helm Vorlagenbefehl, um ein Manifest zu erstellen. Durchsuchen Sie das Manifest nach externen Bildverweisen wie gcr Bildern busybox oder. Laden Sie alle Container-Images zusammen mit Abhängigkeiten in AWS Marketplace Amazon ECR-Repositorys hoch, die mithilfe der Option Add Repository in der Dropdownliste für Anfragen erstellt wurden.
Benutzerdefinierte Konfiguration — Sie können während der Bereitstellung benutzerdefinierte Variablen hinzufügen. Informationen darüber, wie Sie das Endbenutzererlebnis identifizieren, die Software aws_mp_configuration_schema.json benennen und anhand des Helm Diagramms in einen Wrapper packen, finden Sie unter Amazon EKS-Add-ons: Erweiterte Konfiguration.

Gemäß dem Schlüsselwort „$schema“ $schema muss es sich um einen URI handeln, der auf eine gültige application/schema+json Ressource verweist.

Diese Datei darf keine vertraulichen Informationen wie Passwörter, Lizenzschlüssel und Zertifikate akzeptieren.

Für die Verwaltung von Geheimnissen und Zertifikatsinstallationen können Sie den Endbenutzern die Schritte vor oder nach der Add-on Installation zur Verfügung stellen. Das Produkt sollte nicht auf externe Lizenzen angewiesen sein. Das Produkt sollte auf der Grundlage von Rechten AWS Marketplace funktionieren.

Weitere Informationen zu Einschränkungen für finden Sie aws_mp_configuration_schema.json unterAdd-on Konfigurationsanforderungen und bewährte Methoden für Add-On-Anbieter.
Identifizieren und erstellen Sie den Namespace, in dem die Software bereitgestellt wird — In der ersten Version Ihres Produkts müssen Sie den Namespace identifizieren, in dem die Software bereitgestellt wird, indem Sie einen Namespace mit Vorlagen hinzufügen.
Benutzerdefinierte Ressourcendefinitionen (CRDs) — Das Amazon EKS-Addon-Framework unterstützt nicht die Installation von CRDs und benutzerdefinierten Ressourcendeklarationen, die auf CRDs basieren, die mit demselben Add-on angewendet wurden. Wenn Ihr Add-on über benutzerdefinierte Ressourcen verfügt und auf CRDs basiert, können Sie entweder:
- Veröffentlichen Sie zwei Add-Ons: Teilen Sie die CRD-Definition in ein separates Add-on (separates Steuerdiagramm) auf und die eigentliche benutzerdefinierte Ressourceninstallation in ein separates Add-on.
- Veröffentlichen Sie ein einzelnes Add-on mit zusätzlichen manuellen Anweisungen: Veröffentlichen Sie ein einzelnes Add-on, das die CRDs auf dem Cluster installiert. Stellen Sie Nutzungsanweisungen zusammen mit Kubernetes-Manifestdateien bereit, damit Endbenutzer benutzerdefinierte Ressourcen einrichten können, die von diesen CRDs abhängen.
Erstellen Sie die, serviceAccount falls zutreffend — Wenn es sich bei der Software entweder um eine kostenpflichtige Software handelt AWS Marketplace oder eine Verbindung zu einer anderen Software hergestellt werden muss AWS-Services, stellen Sie sicher, dass das Helm Diagramm standardmäßig erstellt wirdserviceAccount. Wenn die serviceAccount Erstellung über einen Parameter in einer values.yaml Datei erfolgt, setzen Sie den Parameterwert auftrue. Beispiel, serviceAccount.create = true. Dies ist erforderlich, da der Kunde das Add-on möglicherweise installieren möchte, indem er Berechtigungen von der zugrunde liegenden Knoteninstanz erbt, die bereits über die erforderlichen Berechtigungen verfügt. Wenn das Helm-Diagramm das nicht erstelltserviceAccount, können die Berechtigungen nicht an das serviceAccount gebunden werden.
Rückverfolgbare Einsätze oder Daemonsets — Stellen Sie sicher, dass Ihr Helm-Diagramm über ein Daemonset oder einen Einsatz verfügt. Das Amazon EKS-Addon-Framework verfolgt mithilfe dieser Ressourcen die Bereitstellung Ihrer Amazon EKS-Ressourcen. Ohne eine rückverfolgbare Bereitstellung oder ein Daemonset wird Ihr Addon mit einem Bereitstellungsfehler konfrontiert. Wenn Ihr Addon kein Deployment oder Daemonset hat, wenn Ihr Addon beispielsweise eine Reihe von benutzerdefinierten Ressourcen oder einen Kubernetes-Job bereitstellt, die nicht rückverfolgbar sind, fügen Sie ein Dummy-Deployment- oder Daemonset-Objekt hinzu.
Unterstützung für AMD- und ARM-Architekturen — Viele Amazon EKS-Kunden verwenden ARM64 heute, um Graviton-Instances zu verwenden. AWS Third-party Software muss beide Architekturen unterstützen.
Integrieren Sie die Lizenzierungs- oder Messing-APIs von AWS Marketplace — AWS Marketplace unterstützt mehrere Abrechnungsmodelle. Weitere Informationen finden Sie unter Integrationen für die Abrechnung, Messung und Lizenzierung von Container-Produkten. Wenn Sie Ihr Produkt über PAYG-Mechanismen verkaufen möchten, finden Sie weitere Informationen unterKonfiguration der benutzerdefinierten Messung für Containerprodukte mit dem AWS Marketplace Metering Service. Wenn Sie Ihr Produkt im Rahmen eines Vorausverkaufs- oder Vertragsmodells verkaufen möchten, finden Sie unter. Vertragspreise für Containerprodukte mit AWS License Manager
Laden Sie die Software und alle Artefakte und Abhängigkeiten hoch — Das Helm-Diagramm muss in sich abgeschlossen sein und darf beispielsweise keine Abhängigkeiten von externen Quellen erfordern. GitHub Wenn die Software externe Abhängigkeiten benötigt, müssen die Abhängigkeiten in AWS Marketplace private Amazon ECR-Repositorys unter derselben Liste übertragen werden. AWS Marketplace
Stellen Sie Anweisungen zur Bereitstellung auf Ihrer Website bereit — Wir bitten Sie, einen Bereitstellungsleitfaden für Kunden bereitzustellen, in dem beschrieben wird, wie Ihre Software mithilfe des Befehls https://docs.aws.amazon.com/cli/latest/reference/eks/create-addon.html create-addon bereitgestellt werden kann.

Add-on permissions/IAM roles — Wenn Ihr von veröffentlichtes Add-on Zugriff auf einen AWS Dienst AWS Marketplace erfordert, sollte Ihre Software über ein Kubernetes-Dienstkonto verfügen, das mit IAM-Richtlinien für den Zugriff auf Dienste versehen ist. AWS Sie können zwischen zwei Optionen für Ihr Dienstkonto wählen, um API-Anfragen an Dienste zu stellen: AWS

Anmeldeinformationen über IRSA: Diese Option ermöglicht es Ihrer Software, Anmeldedaten vom Identity and Access Management (IAM) -Role Service (IRSA) abzurufen. Weitere Informationen finden Sie unter IAM-Rollen für Dienstkonten.
Amazon EKS-Pod-Identität: Mit dieser Option kann Ihre Software die Pod-Identität des Amazon EKS-Pods verwenden, um API-Anfragen an AWS Dienste zu stellen. Weitere Informationen finden Sie unter Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS Dienste gewährt

Ihr Add-on muss über eine zusätzliche Konfigurationsdatei verfügen, die auf der obersten Ebene des Helm-Diagramms im selben Verzeichnis wie das aktuelle benutzerdefinierte Konfigurationsschema (aws_mp_configuration_schema.json) benannt aws_mp_addon_parameters.json ist. Derzeit verarbeitet diese Datei nur Berechtigungen, die mit der Pod-Identität kompatibel sind. Das Dateiformat lautet wie folgt:


{
  "permissions": {
      "isPodIdentityCompatible" : true,
      "permissionsList": [
       {
        "serviceAccount" : "String",
        "managedPolicies" : ["Policy Arn"],
       }
     ]
    }
  }

Name der Datei: aws_mp_addon_parameters.json

Anmerkung

Die aws_mp_addon_parameters.json Datei aktiviert den Add-on Zugriffsbereich auf der Seite mit den Add-on Konfigurationseinstellungen der Amazon EKS-Konsole

Feldname	Typ	Hinweise	Beispielwert
ist PodIdentityCompatible	Boolesch	Derzeit wird nur `true` unterstützt. Das Feld zeigt an, ob die in der folgenden PermissionsList-Liste beschriebenen Berechtigungen zu pod-identity passen	TRUE
ServiceAccount	Zeichenfolge	Der Name des Dienstkontos, das das Add-on für den Zugriff auf die Berechtigungen verwendet	`kpow`
Verwaltete Richtlinien	Liste <String>	Liste der Policy-ARNS, die für dieses Dienstkonto verwendet werden sollen und die vom EKS-Add-on übernommen werden können	`["arn:aws:iam::aws:policy/ReadOnlyAccess"]`

Anmerkung

Pay-as-you-go (PAYG) -Add-On-Produkte von AWS Marketplace können Amazon EKS Pod Identity nicht verwenden und müssen IAM Roles for Service Accounts (IRSA) für die Zugriffskontrolle verwenden.

Versionsupdates — Amazon EKS veröffentlicht einige Wochen nach der Upstream-Veröffentlichung neue Kubernetes-Versionen. Sobald neue Amazon EKS-Cluster-Versionen allgemein verfügbar sind, haben Anbieter 45 Tage Zeit, um ihre Software zu zertifizieren oder zu aktualisieren, damit sie mit der neuen Amazon EKS-Cluster-Version kompatibel ist. Wenn Ihre aktuellen Versionen des Add-ons die neue Kubernetes-Version unterstützen, validieren und zertifizieren Sie diese, damit wir die Versionskompatibilitätsmatrix aktualisieren können. Wenn eine neue Add-on-Version zur Unterstützung der neuen Kubernetes-Version benötigt wird, reichen Sie die neue Version bitte zum Onboarding ein.
Die Software des Partners muss in einen der folgenden Typen fallen oder eine Betriebssoftware sein, die Kubernetes oder Amazon EKS verbessert: Gitops | Monitoring | Logging | Cert-Management | Policy-Management | Kostenmanagement | Autoscaling | Storage | Kubernetes-Management | Service-Mesh | etcd-backup | ingress-service-type | loadbalancer | local-registry| networking | Security | Backup | Ingress-Controller | Observability
Software kann nicht Container Network Interface (CNI) sein.
Software muss über Lizenzierungs AWS Marketplace - und Messing-APIs für kostenpflichtige Produkte verkauft und in diese integriert werden. BYOL-Produkte werden nicht akzeptiert.

Add-on Konfigurationsanforderungen und bewährte Methoden für Add-On-Anbieter

Amazon EKS erfordert eine Konfiguration als https://helm.sh/docs/topics/charts/#schema-files Helm-JSON-Schemazeichenfolge von Zusatzanbietern. Add-ons die entweder erforderliche Konfigurationen benötigen oder optionale Konfigurationen zulassen, müssen eine aws_mp_configuration_schema.json Datei enthalten, an die das Helm-Diagramm gesendet wird AWS Marketplace. Amazon EKS verwendet dieses Schema, um die Konfigurationseingaben von Kunden zu validieren und API-Aufrufe mit Eingabewerten abzulehnen, die nicht dem Schema entsprechen. Add-on Konfigurationen lassen sich in der Regel in zwei Kategorien einteilen:

Konfiguration für allgemeine Kubernetes-Eigenschaften wie Labels, Toleranzen, NodeSelector usw.
Konfigurationen, die für Zusatzmodule spezifisch sind, wie Lizenzschlüssel, Feature-Aktivierung, URLs usw.

Dieser Abschnitt konzentriert sich auf die erste Kategorie, die sich auf allgemeine Kubernetes-Eigenschaften bezieht.

Amazon EKS empfiehlt, die bewährten Methoden zur Konfiguration von Amazon EKS-Add-Ons zu befolgen.

Schema-Anforderungen
Allgemeine Parameter, die für die Konfiguration zulässig sind
Allgemeine Parameter, die für die Konfiguration nicht zulässig sind

Schema-Anforderungen

Stellen Sie bei der Definition des JSON-Schemas sicher, dass Sie eine Version von jsonschema verwenden, die von Amazon EKS-Add-Ons unterstützt wird.

Die Liste der unterstützten Schemas:

https://json-schema.org/draft-04/schema
https://json-schema.org/draft-06/schema
https://json-schema.org/draft-07/schema
https://json-schema.org/draft/2019-09/schema

Die Verwendung einer anderen JSON-Schemaversion ist mit Amazon EKS-Add-Ons nicht kompatibel und führt dazu, dass das Add-on erst veröffentlicht werden kann, wenn dieses Problem behoben ist.

Beispiel für eine Helm-Schemadatei


{
"$schema": "http://json-schema.org/schema#",
  "type": "object",
  "properties": {
"podAnnotations": {
"description": "Pod Annotations"
"type": "object"
    },
    "podLabels": {
"description": "Pod Labels"
"type": "string"
    },
    "resources": {
"type": "object"
"description": "Resources"
    },
    "logLevel": {
"description": "Logging Level"
"type": "string",
      "enum": [
        "info",
        "debug"
      ]
    },
    "config": {
"description": "Custom Configuration"
"type": "object"
    }
  }
}

CamelCase

Die Konfigurationsparameter müssen CamelCase sein und werden abgelehnt, wenn sie nicht diesem Format entsprechen.

Beschreibungen sind erforderlich

Fügen Sie immer aussagekräftige Beschreibungen für Schemaeigenschaften hinzu. Diese Beschreibung wird verwendet, um Labelnamen in der Amazon EKS-Konsole für jeden Konfigurationsparameter zu rendern.

RBAC-Definition

Add-on Anbieter müssen die RBAC-Berechtigungen definieren und bereitstellen, die für eine erfolgreiche Installation des Add-ons nach dem Prinzip der geringsten Rechte erforderlich sind. Wenn sich die RBAC-Berechtigungen für neuere Versionen des Add-ons oder für Korrekturen zur Behebung einer CVE ändern müssen, müssen die Anbieter von Zusatzmodulen das Amazon EKS-Team über diese Änderung informieren. Die erforderlichen Berechtigungen für jede Kubernetes-Ressource sollten auf den Ressourcennamen des Objekts beschränkt sein.


apiGroups: ["apps"]
resources: ["daemonsets"]
resourceNames: ["ebs-csi-node"]
verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]

Verwaltung von Geheimnissen

Dieser Abschnitt gilt nur für Add-Ons, bei denen Kunden geheime Informationen wie Anwendungsschlüssel, API-Schlüssel, Passwort usw. konfigurieren müssen. Derzeit unterstützen Amazon EKS-APIs die Weitergabe geheimer Informationen im Klartext aufgrund der Auswirkungen auf die Sicherheit nicht. Kunden können die Konfiguration jedoch verwenden, um den Namen des Kubernetes-Geheimnisses weiterzugeben, das die für das Add-on benötigten Schlüssel enthält. Kunden müssen als Voraussetzung Kubernetes-Secret-Objekte erstellen, die die Schlüssel mit demselben Namespace enthalten, und dann bei der Erstellung des Add-ons den Namen des Secrets mithilfe des Konfigurations-Blobs eingeben. Wir empfehlen, dass Add-On-Anbieter die Schemaeigenschaften benennen, damit Kunden sie nicht versehentlich mit dem tatsächlichen Schlüssel verwechseln. Zum Beispiel: AppSecretName, Verbindung SecretName usw.

Zusammenfassend lässt sich sagen, dass Add-On-Anbieter das Schema verwenden können, um es Kunden zu ermöglichen, den Namen des Geheimnisses weiterzugeben, aber nicht die Schlüssel, die das Geheimnis selbst enthalten.

Beispiele für Konfigurationswerte

Sie können Konfigurationsbeispiele in Ihr Schema aufnehmen, um Kunden bei der Konfiguration von Add-Ons zu helfen. Das folgende Beispiel stammt aus dem Schema von AWS Distro for OpenTelemetry Add-on.


"examples": [
      {
        "admissionWebhooks": {
          "namespaceSelector": {},
          "objectSelector": {}
        },
        "affinity": {},
        "collector": {
          "amp": {
            "enabled": true,
            "remoteWriteEndpoint": "https://aps-workspaces.us-west-2.amazonaws.com/workspaces/ws-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api/v1/remote_write"
          },
          "cloudwatch": {
            "enabled": true
          },
          "mode": "deployment",
          "replicas": 1,
          "resources": {
            "limits": {
              "cpu": "256m",
              "memory": "512Mi"
            },
            "requests": {
              "cpu": "64m",
              "memory": "128Mi"
            }
          },
          "serviceAccount": {
            "annotations": {},
            "create": true,
            "name": "adot-collector"
          },
          "xray": {
            "enabled": true
          }
        },
        "kubeRBACProxy": {
          "enabled": true,
          "resources": {
            "limits": {
              "cpu": "500m",
              "memory": "128Mi"
            },
            "requests": {
              "cpu": "5m",
              "memory": "64Mi"
            }
          }
        },
        "manager": {
          "env": {},
          "resources": {
            "limits": {
              "cpu": "100m",
              "memory": "128Mi"
            },
            "requests": {
              "cpu": "100m",
              "memory": "64Mi"
            }
          }
        },
        "nodeSelector": {},
        "replicaCount": 1,
        "tolerations": []
      }
    ]

Allgemeine Parameter, die für die Konfiguration zulässig sind

Die folgenden Parameter werden in einer Helm-Schemadatei für Kunden empfohlen.

Parameter	Description	Sollte es eine Standardeinstellung geben?
Zusätzliche Beschriftungen	Fügen Sie Kubernetes-Labels zu allen Kubernetes-Objekten hinzu, die vom Add-on verwaltet werden.	Nein
Zusätzliche Anmerkungen	Fügen Sie Kubernetes-Anmerkungen zu allen Kubernetes-Objekten hinzu, die vom Add-on verwaltet werden.	Nein
PodLabels	Fügen Sie Kubernetes-Labels zu Pods hinzu, die vom Add-on verwaltet werden.	Nein
Pod-Anmerkungen	Fügen Sie Kubernetes-Annotationen zu Pods hinzu, die vom Add-on verwaltet werden.	Nein
logLevel	Protokollebene für Komponenten, die vom Add-on verwaltet werden.	Ja
nodeSelector	Einfachste empfohlene Form der Beschränkung der Knotenauswahl. Sie können das NodeSelector-Feld zu Ihrer Pod-Spezifikation hinzufügen und die Knotenbezeichnungen angeben, die der Zielknoten haben soll.	Potenziell, zum Beispiel nur Linux-Knoten
Toleranzen	Toleranzen werden auf Pods angewendet. Toleranzen ermöglichen es dem Scheduler, Pods mit passenden Taints zu planen. Toleranzen ermöglichen zwar die Planung, garantieren aber nicht die Planung.	Vielleicht häufiger bei Daemonsets
Affinität	Die Affinitätsfunktion besteht aus zwei Arten von Affinität: Die NodeAffinität funktioniert wie das NodeSelector-Feld, ist jedoch aussagekräftiger und ermöglicht die Angabe von weichen Regeln. Mit Inter-pod affinity/anti -affinity können Sie Pods gegen Labels auf anderen Pods einschränken.	Vielleicht
Topologie SpreadConstraints	Sie können Topologiestreuungsbeschränkungen verwenden, um zu steuern, wie Pods in Ihrem Cluster auf Ausfalldomänen wie Regionen, Zonen, Knoten und andere benutzerdefinierte Topologiedomänen verteilt werden. Dies kann dazu beitragen, eine hohe Verfügbarkeit sowie eine effiziente Ressourcennutzung zu erreichen.	Vielleicht
Ressource request/limits	Geben Sie an, wie viel cpu/memory jeder Container benötigt. Es wird dringend empfohlen, Anfragen zu stellen. Grenzwerte sind optional.	Ja
Replikate	Anzahl der Replikate der Pods, die vom Add-on verwaltet werden. Gilt nicht für Daemonsets.	Ja

Anmerkung

Bei den Konfigurationsparametern für die Workload-Planung müssen Sie möglicherweise die Komponenten der obersten Ebene im Schema heraustrennen, sofern dies erforderlich ist. Beispiel: Der Amazon EBS-CSI-Treiber enthält zwei Hauptkomponenten, den Controller und den Node-Agent. Kunden benötigen selectors/tolerations für jede Komponente einen anderen Knoten.

Anmerkung

Die im JSON-Schema definierten Standardwerte dienen ausschließlich der Benutzerdokumentation und ersetzen nicht die Notwendigkeit, die richtigen Standardwerte in der values.yaml Datei zu haben. Wenn Sie die Standardeigenschaft verwenden, stellen Sie bitte sicher, dass die Standardeinstellung in mit der im Schema values.yaml übereinstimmt und die beiden Artefakte (values.schema.jsonundvalues.yaml) synchronisiert bleiben, wenn Änderungen am Helm-Diagramm vorgenommen werden.


"affinity": {
            "default": {
              "affinity": {
                "nodeAffinity": {
                  "preferredDuringSchedulingIgnoredDuringExecution": [
                    {
                      "preference": {
                        "matchExpressions": [
                          {
                            "key": "eks.amazonaws.com/compute-type",
                            "operator": "NotIn",
                            "values": [
                              "fargate"
                            ]
                          }
                        ]
                      },
                      "weight": 1
                    }
                  ]
                },
                "podAntiAffinity": {
                  "preferredDuringSchedulingIgnoredDuringExecution": [
                    {
                      "podAffinityTerm": {
                        "labelSelector": {
                          "matchExpressions": [
                            {
                              "key": "app",
                              "operator": "In",
                              "values": [
                                "ebs-csi-controller"
                              ]
                            }
                          ]
                        },
                        "topologyKey": "kubernetes.io/hostname"
                      },
                      "weight": 100
                    }
                  ]
                }
              }
            },
            "description": "Affinity of the controller pod",
            "type": [
              "object",
              "null"
            ]
          }

Allgemeine Parameter, die für die Konfiguration nicht zulässig sind

Cluster-Metadatenparameter wie clusterName regionvpcId,accountId, und andere können von verschiedenen Add-Ons (z. B. Elastic Load Balancing Controller) benötigt werden. Alle ähnlichen Parameter, die dem Amazon EKS-Service bekannt sind, werden automatisch von den Amazon EKS-Add-Ons hinzugefügt und es liegt nicht in der Verantwortung des Benutzers, sie als Konfigurationsoption anzugeben. Zu diesen Parametern gehören:

AWS Region
Name des Amazon EKS-Clusters
VPC-ID des Clusters
Container-Registry, speziell für Build-Prod-Konten, die von Netzwerk-Add-Ons verwendet wird
DNS-Cluster-IP, speziell für das Coredns-Add-On
Amazon EKS-Cluster-API-Endpunkt
IPv4 ist auf dem Cluster aktiviert
IPv6 auf dem Cluster aktiviert
Präfixdelegierung für IPv6 auf dem Cluster aktiviert

Add-on Anbieter müssen sicherstellen, dass Sie Vorlagen für solche zutreffenden Parameter definiert haben. Jeder der oben genannten Parameter hat ein vordefiniertes parameterType Attribut, das von Amazon EKS definiert wird. Die Release-Metadaten spezifizieren die Zuordnung zwischen dem parameterType und dem name/path des Parameters in der Vorlage. Auf diese Weise können die Werte von Amazon EKS dynamisch weitergegeben werden, ohne dass Kunden sie über Konfigurationen angeben müssen. Außerdem erhalten Add-On-Anbieter die Flexibilität, ihre eigene Vorlage zu definieren. name/path Parameter wie die oben genannten, die Amazon EKS dynamisch einfügen muss, sollten aus der Schemadatei ausgeschlossen werden.

Beispiel für eine Zuordnung aus Release-Metadaten


"defaultConfiguration": [
       {
            "key": "image.containerRegistry",
            "parameterType": "CONTAINER_REGISTRY"
       }
]

Es wird nicht empfohlen, die folgenden Parameter in einer Helm-Schemadatei für Kunden zu konfigurieren. Entweder sollten die Parameter nicht änderbare Standardwerte haben oder überhaupt nicht in der Add-On-Vorlage enthalten sein.

Parameter	Description	Sollte es eine Standardeinstellung geben?
Abbild	Container-Image, das auf dem Kubernetes-Cluster bereitgestellt wird.	Nein, wird über eine Zusatzdefinition verwaltet
Bild PullSecrets	Konfiguration eines Pods für die Verwendung eines Geheimnisses zum Abrufen aus einer privaten Registrierung.	N/A
LivenessProbe	Der Kubelet-Prozess verwendet Liveness Probes, um zu wissen, wann ein Container neu gestartet werden muss. Liveness Probes könnten beispielsweise einen Deadlock abfangen, bei dem eine Anwendung läuft, aber keinen Fortschritt erzielen kann. Ein Neustart eines Containers in einem solchen Zustand kann dazu beitragen, dass die Anwendung trotz Bugs besser verfügbar ist.	Ja
Readiness-Sonde	Es ist wichtig, dass Sie eine Bereitschaftsprüfung für Ihre Container haben. Auf diese Weise weiß der Kubelet-Prozess, der auf Ihrer Datenebene läuft, wann der Container bereit ist, den Datenverkehr abzuwickeln. Ein Pod gilt als bereit, wenn alle seine Container bereit sind. Dieses Signal wird unter anderem verwendet, um zu steuern, welche Pods als Backends für Dienste verwendet werden. Wenn ein Pod nicht bereit ist, wird er aus den Service Load Balancern entfernt.	Ja
Probe starten	Das Kubelet verwendet Starttests, um festzustellen, wann eine Container-Anwendung gestartet wurde. Wenn ein solcher Test konfiguriert ist, deaktiviert er die Verfügbarkeits- und Bereitschaftsprüfungen, bis er erfolgreich ist. Dadurch wird sichergestellt, dass diese Tests den Start der Anwendung nicht beeinträchtigen. Dies kann verwendet werden, um die Verfügbarkeit von Containern zu überprüfen, die langsam starten. So wird verhindert, dass sie vom Kubelet getötet werden, bevor sie betriebsbereit sind.	Optional
Schote DisruptionBudget	Definieren Sie ein Pod-Disruption-Budget (PDB), um sicherzustellen, dass bei freiwilligen Unterbrechungen eine Mindestanzahl von PODS weiterläuft. Eine PDB begrenzt die Anzahl der Pods einer replizierten Anwendung, die aufgrund freiwilliger Unterbrechungen gleichzeitig ausgefallen sind. Eine quorumbasierte Anwendung möchte beispielsweise sicherstellen, dass die Anzahl der ausgeführten Replikate nie unter die für ein Quorum erforderliche Anzahl sinkt. Ein Web-Frontend möchte möglicherweise sicherstellen, dass die Anzahl der Replikate, die die Last verarbeiten, niemals unter einen bestimmten Prozentsatz der Gesamtzahl fällt.	Ja, wenn standardmäßig mehr als zwei Replikate verwendet werden
ServiceAccount (Name)	Name des Dienstkontos, unter dem die Pods ausgeführt werden.	Ja
ServiceAccount (Anmerkungen)	Anmerkungen, die auf das Dienstkonto angewendet wurden. Wird in der Regel für die Funktion „IAM-Rollen für Dienstkonten“ verwendet	Nein, der ARN für die Rolle des IAM-Dienstkontos ist in der übergeordneten Amazon EKS-Add-On-API festgelegt. Eine Ausnahme von dieser Regel ist, wenn Ihr Add-on mehrere deployments/controllers (wie Flux) hat und separate IRSA-Rollen-ARNs erfordert.
Priorität ClassName	Die Priorität gibt an, wie wichtig ein Pod im Vergleich zu anderen Pods ist. Wenn ein Pod nicht geplant werden kann, versucht der Scheduler, Pods mit niedrigerer Priorität zu verhindern (zu entfernen), um die Planung des ausstehenden Pods zu ermöglichen.	Ja. Die meisten Add-Ons sind für die Cluster-Funktionalität von entscheidender Bedeutung und sollten standardmäßig eine Prioritätsklasse haben.
Pod SecurityContext	Ein Sicherheitskontext definiert die Rechte- und Zugriffskontrolleinstellungen für einen Pod oder Container. Wird in der Regel verwendet, um fsGroup festzulegen, was für IRSA in Clustern der Version 1.19 und niedriger erforderlich war.	Unwahrscheinlich, da Amazon EKS Kubernetes v1.19 nicht mehr unterstützt
Sicherheitskontext	Ein Sicherheitskontext definiert die Rechte- und Zugriffskontrolleinstellungen für einen Pod oder Container.	Ja
Strategie aktualisieren	Gibt die Strategie an, mit der alte Pods durch neue ersetzt werden.	Ja
NameOverride	Überschreibt den Namen der Pods.	Nein
Pod SecurityPolicy	Setzen Sie Einschränkungen für Parameter durch.	Nein — PSPs sind veraltet
extraVolumeMounts/extraVolumes	Wird für IRSA in Clustern verwendet, die nicht von Amazon EKS stammen.	Nein

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Testen und veröffentlichen Sie Ihr Produkt

Preisgestaltung für Container-Produkte