Produktanforderungen auf Containerbasis für AWS Marketplace - AWS Marketplace
Anforderungen an SicherheitZugriffsvoraussetzungenAnforderungen bezüglich KundeninformationenAnforderungen an die ProduktnutzungArchitekturanforderungenAnweisungen zur Verwendung von Container-ProduktenAnforderungen für EKS Amazon-Zusatzprodukte

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Produktanforderungen auf Containerbasis für AWS Marketplace

AWS Marketplace hält die folgenden Anforderungen für alle containerbasierten Produkte und Angebote aufrecht. 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, um den Anforderungen ihrer spezifischen Produkte gerecht zu werden.

Alle Produkte und die zugehörigen Metadaten werden bei der Einreichung überprüft, um sicherzustellen, dass sie die aktuellen AWS Marketplace Anforderungen erfüllen oder übertreffen. Wir überprüfen diese Richtlinien und passen sie an, um unseren sich ändernden Sicherheits- und anderen Nutzungsanforderungen gerecht zu werden. AWS Marketplace überprüft kontinuierlich, ob bestehende Produkte weiterhin alle Änderungen dieser Anforderungen erfüllen. Wenn Produkte nicht den Vorschriften entsprechen, AWS Marketplace wird wir Sie kontaktieren, um Ihr Produkt zu aktualisieren. In einigen Fällen ist Ihr Produkt möglicherweise vorübergehend für neue Abonnenten nicht verfügbar, bis Probleme behoben sind.

Anforderungen an Sicherheit

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

  • Docker-Container-Images müssen frei von bekannter Malware, Viren oder Sicherheitslücken sein. Wenn Sie Ihrem Container-Produkt eine neue Version hinzufügen, werden die in der Version enthaltenen Container-Images gescannt.

  • Wenn Ihre containerbasierten Produkte Zugriff zur Verwaltung von AWS Ressourcen benötigen, muss der Zugriff über IAMRollen für Dienstkonten (wenn sie über Amazon Elastic Kubernetes Service (AmazonEKS) ausgeführt werden) oder IAMRollen für Aufgaben (wenn sie über Amazon Elastic Container Service (AmazonECS) ausgeführt werden) erfolgen, anstatt einen Zugriffsschlüssel von Benutzern anzufordern.

  • Container-basierte Produkte dürfen nur die geringsten Rechte benötigen, um ausgeführt zu werden. Weitere Informationen finden Sie unter ECSSicherheit und EKS Schutz.

  • Container-Images sollten standardmäßig so konfiguriert werden, dass sie ohne Root-Rechte ausgeführt werden.

Zugriffsvoraussetzungen

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

  • Container-basierte Produkte müssen ein zufälliges Anfangskennwort verwenden. Container-basierte Produkte dürfen keine festen oder leeren Ausgangskennwörter für den externen Administratorzugriff verwenden (z. B. um sich über eine Webschnittstelle bei der Anwendung anzumelden). Der Käufer muss zur Eingabe dieses zufälligen Passworts aufgefordert werden, bevor er seine eigenen Anmeldeinformationen einrichten oder ändern kann.

  • Jeder Zugriff von außen auf die Anwendung muss ausdrücklich genehmigt und vom Kunden aktiviert werden.

Anforderungen bezüglich Kundeninformationen

Alle Produkte, die in Behältern hergestellt werden, müssen die folgenden Anforderungen an Kundeninformationen erfüllen:

  • Software darf ohne Wissen und ausdrückliche Zustimmung des Kunden keine Kundendaten sammeln oder exportieren, es sei denn, dies ist durch BYOL (Bring Your Own License) vorgeschrieben. Anwendungen, die Kundendaten sammeln oder exportieren, müssen diesen Richtlinien entsprechen:

    • Die Erfassung der Kundendaten muss eigenständig, automatisiert und sicher erfolgen. Käufer dürfen nicht warten müssen, bis die Verkäufer die Bereitstellung der Software genehmigen.

    • Die Anforderungen an Kundendaten müssen in der Beschreibung oder den Nutzungshinweisen des Angebots eindeutig angegeben sein. Dazu gehören, was gesammelt wird, wo die Kundendaten gespeichert werden und wie sie verwendet werden. Dieses Produkt erfasst beispielsweise Ihren Namen und Ihre E-Mail-Adresse. Diese Informationen werden an die gesendet und dort gespeichert<company name>. Diese Informationen werden nur verwendet, um den Käufer in Bezug auf die zu kontaktieren. <product name>

    • Zahlungsinformationen dürfen nicht gesammelt werden.

Anforderungen an die Produktnutzung

Alle Produkte, die in Behältern hergestellt werden, müssen die folgenden Anforderungen für die Produktnutzung erfüllen:

  • Verkäufer können nur voll funktionsfähige Produkte anbieten. Beta- oder Vorabversionen von Produkten zu Test- oder Testzwecken 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 gleichwertige kostenpflichtige Version bereitstellt.

  • Sämtliche Nutzungsanweisungen für ein containergestütztes Produkt 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-basierte Produkte müssen alle Container-Images enthalten, die ein Abonnent benötigt, um die Software zu verwenden. Darüber hinaus dürfen containerbasierte Produkte nicht erfordern, dass ein Benutzer das Produkt mit Bildern von außerhalb startet AWS Marketplace (z. B. Container-Images aus Repositorys von Drittanbietern).

  • Container und ihre Software müssen als Self-Service-Lösung bereitgestellt werden können und dürfen keine zusätzlichen Zahlungsmethoden oder Kosten erfordern. Anwendungen, für deren Bereitstellung externe Abhängigkeiten erforderlich sind, müssen den folgenden Richtlinien entsprechen:

    • Die Anforderung muss in der Beschreibung oder den Nutzungshinweisen des Angebots angegeben werden. Für die ordnungsgemäße Bereitstellung dieses Produkts ist beispielsweise eine Internetverbindung erforderlich. Die folgenden Pakete werden bei der Bereitstellung heruntergeladen:. <list of package>

    • Verkäufer sind für die Nutzung und Sicherstellung 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.

    • Die externen Abhängigkeiten dürfen keine zusätzlichen Zahlungsmethoden oder Kosten erfordern.

  • Container, die eine ständige Verbindung zu externen Ressourcen erfordern, die nicht der direkten Kontrolle des Käufers unterliegen — z. B. externe APIs oder vom Verkäufer oder einem Dritten AWS-Services verwaltete Ressourcen — müssen die folgenden Richtlinien einhalten:

    • 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>

    • Die Verkäufer sind für die Nutzung und Sicherstellung 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 anfallen 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 Add-on zu einem anderen Produkt oder einem Produkt eines anderen ISV Unternehmens handelt, muss in Ihrer Produktbeschreibung angegeben werden, dass es die Funktionalität des anderen Produkts erweitert und dass Ihr Produkt ohne dieses Produkt nur sehr begrenzt nützlich ist. Dieses Produkt erweitert beispielsweise die Funktionalität von und ohne dieses Produkt hat dieses Produkt nur einen sehr begrenzten Nutzen. <product name> Bitte beachten Sie, dass für den vollen Funktionsumfang dieses Angebots möglicherweise eine eigene Lizenz erforderlich ist. <product name>

Architekturanforderungen

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

  • Die Container-Quellbilder für AWS Marketplace müssen in das Amazon Elastic Container Registry (AmazonECR) -Repository übertragen werden, das Eigentum von ist AWS Marketplace. Sie können diese Repositorys in den Produkten AWS Marketplace Management Portal unter dem Server für jedes Ihrer Container-Produktangebote erstellen.

  • Container-Images müssen auf Linux basieren.

  • Bezahlte Produkte auf Containerbasis müssen bei Amazon ECSEKS, Amazon oder bereitgestellt werden können. AWS Fargate

  • Bezahlte containerbasierte Produkte mit Vertragspreisen und einer Integration mit AWS License Manager sollten auf AmazonEKS, Amazon, Amazon AnywhereECS, Amazon EKS Anywhere AWS Fargate, Red Hat OpenShift Service on AWS (ROSA), selbstverwalteten Kubernetes-Clustern vor Ort oder auf Amazon ECS Elastic Compute Cloud bereitgestellt werden.

Anweisungen zur Verwendung von Container-Produkten

Folgen Sie bei der Erstellung von Nutzungsanweisungen für Ihr Containerprodukt die Schritte und Anleitungen unterAnweisungen zur Erstellung AMI und Verwendung von Behältern von Produkten für AWS Marketplace.

Anforderungen für EKS Amazon-Zusatzprodukte

Ein EKS Amazon-Add-on ist Software, die Betriebsfunktionen bietet für Kubernetes Anwendungen, die jedoch nicht spezifisch für die Anwendung sind. Ein EKS Amazon-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 Speicher zu interagieren.

Als Verkäufer von Containerprodukten können Sie zwischen verschiedenen Bereitstellungsoptionen wählen, darunter AmazonEKS. Sie können eine Version Ihres Produkts als AWS Marketplace Add-on im EKS Amazon-Zusatzkatalog veröffentlichen. Ihr Add-on wird in der EKS Amazon-Konsole neben Add-Ons angezeigt, die von AWS und 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 EKSAmazon-Add-Ons im EKSAmazon-Benutzerhandbuch.

Bereiten Sie Ihr Container-Produkt als AWS Marketplace Zusatzprodukt vor

Um Ihr Container-Produkt 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 für beide AMD64 ARM64 Architekturen kompatibel sein.

  • Ihr Container-Produkt darf nicht das Preismodell Bring Your Own License (BYOL) verwenden.

    Anmerkung

    BYOLwird für die EKS Amazon-Zusatzlieferung nicht unterstützt.

  • Sie müssen alle Anforderungen an containerbasierte Produkte erfüllen, einschließlich der Übertragung aller Container-Bilder und Helm Diagramme in AWS Marketplace verwaltete ECR Amazon-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, Docker Hub, und Quay.

  • Helm Diagramme — Bereiten Sie Ihre Software auf die Bereitstellung vor, indem Sie Helm Diagramm. Das EKS Amazon-Add-On-Framework konvertiert eine Helm Diagramm in ein Manifest. Etwas Helm Funktionen werden in EKS Amazon-Systemen nicht unterstützt. In der folgenden Liste werden die Anforderungen beschrieben, die vor dem Onboarding erfüllt sein müssen. In dieser Liste sind alle Helm Befehle verwenden Helm Version 3.8.1:

    • Alle Capabilities Objekte werden unterstützt, mit Ausnahme .APIVersions von. .APIVersionswird für non-built-in benutzerdefinierte Anwendungen nicht unterstützt Kubernetes APIs.

    • Nur die Release.Namespace Objekte Release.Name und werden unterstützt.

    • Helm Hooks und die lookup Funktion werden nicht unterstützt.

    • Alle abhängigen Diagramme müssen sich innerhalb des Hauptdiagramms befinden Helm Diagramm (angegeben mit dem Repository-Pfad file://...).

    • Das Tool Helm Das Diagramm muss erfolgreich bestanden werden Helm Lint und Helm Vorlage ohne Fehler. Die Befehle lauten wie folgt:

      • Helm Fussel — 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

      • Helm Vorlage — 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 der —f Flagge.

    • Speichern Sie alle Container-Binärdateien in AWS Marketplace ECR Amazon-Repos. Um ein Manifest zu erstellen, verwenden Sie den Helm Template-Befehl, der zuvor gezeigt wurde. Suchen Sie im Manifest nach externen Bildverweisen wie busybox gcr Bildern. Laden Sie alle Container-Images zusammen mit Abhängigkeiten in AWS Marketplace ECR Amazon-Repos hoch, die mithilfe der Option Repository hinzufügen in der Dropdownliste für Anfragen erstellt wurden.

  • Benutzerdefinierte Konfiguration — Sie können während der Bereitstellung benutzerdefinierte Variablen hinzufügen. Informationen zur Identifizierung der Benutzererfahrung finden Sie, indem Sie der Software einen Namen geben und sie in einen Wrapper packenaws_mp_configuration_schema.json, der Helm Diagramm, siehe EKSAmazon-Add-Ons: Erweiterte Konfiguration.

    Laut dem Schlüsselwort „$schema“ $schema muss es sich um ein Objekt handelnURI, das auf eine gültige application/schema+json Ressource verweist.

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

    Um die Installation von Geheimnissen und Zertifikaten zu handhaben, können Sie Endbenutzern Schritte nach der pre-Add-on Installation oder Installation zur Verfügung stellen. Das Produkt sollte nicht auf externe Lizenzen angewiesen sein. Das Produkt sollte auf der Grundlage von AWS Marketplace Berechtigungen funktionieren.

    Weitere Informationen zu Einschränkungen für finden Sie aws_mp_configuration_schema.json unterAnforderungen an die Konfiguration von Add-ons 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, in dem die Software bereitgestellt werden soll, identifizieren, indem Sie einen Namespace mit Vorlagen hinzufügen.

  • Erstellen Sie den, serviceAccount falls zutreffend — Wenn es sich bei der Software entweder um eine kostenpflichtige Software handelt AWS Marketplace oder eine Verbindung zu einer anderen AWS-Services Software hergestellt werden muss, stellen Sie sicher, dass Helm Das Diagramm wird serviceAccount standardmäßig erstellt. Wenn die serviceAccount Erstellung über einen Parameter in einer values.yaml Datei erfolgt, legen Sie den Parameterwert auf festtrue. Beispiel, serviceAccount.create = true. Dies ist erforderlich, da der Kunde das Add-on möglicherweise installieren möchte, indem er die 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 auch nicht mit dem serviceAccount verknüpft werden.

  • Rückverfolgbare Bereitstellungen oder Daemonsets — Stellen Sie sicher, dass Ihr Helm-Diagramm über ein Daemonset oder eine Bereitstellung verfügt. Das Amazon EKS Addon Framework verfolgt die Bereitstellung Ihrer EKS Amazon-Ressourcen mithilfe dieser Ressourcen. Ohne eine rückverfolgbare Bereitstellung oder ein Daemonset tritt bei Ihrem Addon ein Bereitstellungsfehler auf. 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.

  • Support für AMD und ARM Architekturen — Viele EKS Amazon-Kunden nutzen ARM64 heute AWS Graviton-Instances. Software von Drittanbietern muss beide Architekturen unterstützen.

  • Integration mit Lizenzierung oder Abrechnung 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 Vorabverkaufs- oder Vertragsmodells verkaufen möchten, finden Sie weitere Informationen unterVertragspreise für Containerprodukte mit AWS License Manager.

  • Laden Sie die Software und alle Artefakte und Abhängigkeiten hoch — Das Helm-Diagramm muss eigenständig sein und darf keine Abhängigkeiten von externen Quellen erfordern, z. B. GitHub. Wenn für die Software externe Abhängigkeiten erforderlich sind, müssen die Abhängigkeiten in AWS Marketplace private ECR Amazon-Repositorys unter derselben AWS Marketplace Liste übertragen werden.

  • 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 create-addon bereitgestellt werden kann.

  • IAMRollen — Listet alle AWS Identity and Access Management (IAM) Richtlinien auf, die erforderlich sind, damit Ihre Software funktioniert oder sich mit anderen verbindet. AWS-Services

  • Versionsupdates — Amazon EKS veröffentlicht einige Wochen nach der Upstream-Version neue Kubernetes-Versionen. Sobald neue EKS Amazon-Cluster-Versionen allgemein verfügbar sind, haben Anbieter 45 Tage Zeit, um ihre Software zu zertifizieren oder zu aktualisieren, damit sie mit der neuen EKS Amazon-Cluster-Version kompatibel ist. Wenn Ihre aktuellen Versionen des Add-ons die neue Kubernetes-Version unterstützen, überprüfen und zertifizieren Sie diese, damit wir die Versionskompatibilitätsmatrix aktualisieren können. Wenn eine neue Add-On-Version benötigt wird, um die neue Version der Kubernetes-Version zu unterstützen, reichen Sie bitte die neue Version zum Onboarding ein.

  • Die Software des Partners muss in einen der folgenden Typen fallen oder eine betriebsbereite Software sein, die Kubernetes oder Amazon erweitertEKS: Gitops | Monitoring | Logging | Cert-Management | Policy-Management | Cost-Management | Autoscaling | Storage | Kubernetes-Management | Service-Mesh | etcd-backup | | Load-Balancer | Local-Registry| Networking | Sicherheit | Backup | Ingress-Controller | Observability ingress-service-type

  • Software kann nicht Container Network Interface () sein. CNI

  • Software muss im Rahmen von Licensing AWS Marketplace and Metering APIs für kostenpflichtige Produkte verkauft und in diese integriert werden. BYOLProdukte werden nicht akzeptiert.

Anforderungen an die Konfiguration von Add-ons und bewährte Methoden für Add-On-Anbieter

Amazon EKS benötigt die Konfiguration als JSONHelm-Schemazeichenfolge von Add-On-Anbietern. Add-ons, für die entweder erforderliche Konfigurationen erforderlich sind oder optionale Konfigurationen zulassen, müssen eine aws_mp_configuration_schema.json Datei mit dem Helm-Diagramm enthalten, an die gesendet wird AWS Marketplace. Amazon verwendet EKS dieses Schema, um die Konfigurationseingaben von Kunden zu validieren und API Anrufe mit Eingabewerten abzulehnen, die nicht dem Schema entsprechen. Zusatzkonfigurationen lassen sich in der Regel in zwei Kategorien einteilen:

  • Konfiguration für allgemeine Kubernetes-Eigenschaften wie Labels, Toleranzen usw. nodeSelector

  • Add-On-spezifische Konfigurationen wie Lizenzschlüssel, Aktivierung von Funktionen usw. URLs

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

Amazon EKS empfiehlt, sich bei der Konfiguration von EKS Amazon-Add-Ons an bewährte Methoden zu halten.

Schema-Anforderungen

Stellen Sie bei der Definition des JSON-Schemas sicher, dass Sie eine Version von jsonschema verwenden, die von EKS Amazon-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 EKS Amazon-Add-Ons nicht kompatibel und führt dazu, dass das Add-on erst veröffentlicht werden kann, wenn dies 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

Konfigurationsparameter müssen diesem Format camelCase entsprechen und werden abgelehnt, wenn sie nicht eingehalten werden.

Beschreibungen sind erforderlich

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

RBACDefinition

Add-On-Anbieter müssen die für die erfolgreiche Installation des Add-ons erforderlichen RBAC Berechtigungen definieren und bereitstellen. Dabei gilt das Prinzip der geringsten Rechte. Wenn sich die RBAC Berechtigungen für neuere Versionen des Add-ons oder irgendwelche Korrekturen zur Behebung eines Problems ändern müssenCVE, müssen die Add-On-Anbieter das EKS Amazon-Team über diese Änderung informieren. Die erforderlichen Berechtigungen für jede Kubernetes-Ressource sollten auf den Ressourcennamen des Objekts beschränkt werden. 

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

Dieser Abschnitt bezieht sich nur auf Add-Ons, bei denen Kunden geheime Informationen wie Anwendungsschlüssel, API Schlüssel, Passwort usw. konfigurieren müssen. Derzeit unterstützt Amazon EKS APIs die Weitergabe geheimer Informationen im Klartext aus Sicherheitsgründen nicht. Kunden können jedoch die Konfiguration verwenden, um den Namen des Kubernetes-Secrets weiterzugeben, das die für das Add-on benötigten Schlüssel enthält. Kunden müssen als erforderlichen Schritt 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 übergeben. Wir empfehlen, dass Add-On-Anbieter die Schemaeigenschaften benennen, damit Kunden sie nicht versehentlich mit dem tatsächlichen Schlüssel verwechseln. Zum Beispiel: appSecretName, connectionSecretName usw.

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

Beispiele für Konfigurationswerte

Sie können Konfigurationsbeispiele in Ihr Schema aufnehmen, um Kunden bei der Konfiguration von Add-Ons zu unterstützen. 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 kundenseitigen Helm-Schemadatei empfohlen.

Parameter Beschreibung Sollte es eine Standardeinstellung geben?
additionalLabels Fügen Sie allen Kubernetes-Objekten, die vom Add-on verwaltet werden, Kubernetes-Labels hinzu. Nein
additionalAnnotations Fügen Sie allen vom Add-on verwalteten Kubernetes-Objekten Kubernetes-Anmerkungen hinzu. Nein
podLabels Fügen Sie Kubernetes-Labels zu Pods hinzu, die vom Add-on verwaltet werden. Nein
podAnnotations Fügen Sie Kubernetes-Anmerkungen 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 Einschrä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 einzuplanen. Toleranzen ermöglichen eine Terminplanung, garantieren aber keine Terminplanung. Vielleicht häufiger bei Daemonsets
Affinität Die Affinitätsfunktion besteht aus zwei Arten von Affinität: Die Knotenaffinität funktioniert wie das nodeSelector Feld, ist aber aussagekräftiger und ermöglicht die Angabe von Soft-Rules. Mit der Affinität/Anti-Affinität zwischen Pods können Sie Pods anhand von Labels auf anderen Pods einschränken. Vielleicht
topologySpreadConstraints Mithilfe von Beschränkungen für die Topologieverteilung können Sie steuern, wie Pods in Ihrem Cluster auf Fehlerdomä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
Ressourcenanforderung/-limits Geben Sie an, wie viel CPU/Speicher jeder Container benötigt. Es wird dringend empfohlen, Anfragen einzustellen. Grenzwerte sind optional. Ja
Nachbildungen Anzahl der Replikate der vom Add-on verwalteten Pods. Gilt nicht für Daemonsets. Ja
Anmerkung

Bei Konfigurationsparametern für die Arbeitslastplanung müssen Sie gegebenenfalls die Komponenten der obersten Ebene im Schema trennen. Beispiel: Der EBS CSI Amazon-Treiber enthält zwei Hauptkomponenten, Controller und Node-Agent. Kunden benötigen für jede Komponente unterschiedliche Knotenselektoren/Toleranzen.

Anmerkung

Die im JSON Schema definierten Standardwerte dienen ausschließlich der Benutzerdokumentation und ersetzen nicht die Notwendigkeit, den richtigen Standardwert in der Datei zu haben. values.yaml Wenn Sie die Standardeigenschaft verwenden, stellen Sie bitte sicher, dass die Standardeinstellung mit der im Schema values.yaml übereinstimmt und dass die beiden Artefakte (values.schema.jsonundvalues.yaml) synchron 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 clusterNameregion,vpcId,accountId, und andere können für verschiedene Add-Ons (z. B. Elastic Load Balancing Controller) erforderlich sein. Alle ähnlichen Parameter, die dem EKS Amazon-Service bekannt sind, werden automatisch von EKS Amazon-Add-Ons eingefügt und liegen nicht in der Verantwortung des Benutzers, sie als Konfigurationsoption anzugeben. Zu diesen Parametern gehören:

  • AWS Region

  • EKSAmazon-Clustername

  • VPCID des Clusters

  • Container-Registry, speziell für Build-Prod-Konten, die von Netzwerk-Add-Ons verwendet wird

  • DNSCluster-IP, speziell für das CoreDNS-Add-On

  • EKSAPIAmazon-Cluster-Endpunkt

  • IPv4auf dem Cluster aktiviert

  • IPv6auf dem Cluster aktiviert

  • Präfix-Delegierung für IPv6 aktiviert auf dem Cluster

Add-On-Anbieter müssen sicherstellen, dass Sie Templates für diese anwendbaren Parameter definiert haben. Jeder der oben genannten Parameter hat ein von Amazon EKS definiertes vordefiniertes parameterType Attribut. Die Release-Metadaten spezifizieren die Zuordnung zwischen parameterType und. name/path of the parameter in the template. This way, the values can be dynamically passed-in by Amazon EKS without requiring customers to specify these through configurations and also gives flexibility to add-on providers to define their own template name/path Parameter wie die oben genannten, die Amazon dynamisch einfügen EKS muss, sollten aus der Schemadatei ausgeschlossen werden.

Beispiel für eine Zuordnung anhand von Release-Metadaten

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

Die folgenden Parameter sollten nicht in einer kundenseitigen Helm-Schemadatei konfiguriert werden. Entweder sollten die Parameter nicht änderbare Standardwerte haben oder sie sollten überhaupt nicht in der Add-On-Vorlage enthalten sein.

Parameter Beschreibung Sollte es eine Standardeinstellung geben?
Abbild Container-Image, das auf dem Kubernetes-Cluster bereitgestellt wird. Nein, wird über die Add-On-Definition verwaltet
imagePullSecrets Konfiguration eines Pods für die Verwendung eines Geheimnisses zum Abrufen aus einer privaten Registrierung. N/A
livenessProbe Der Kubelet-Prozess verwendet Verfügbarkeitstests, um zu ermitteln, wann ein Container neu gestartet werden muss. Beispielsweise könnten Verfügbarkeitstests einen Deadlock catch, bei dem eine Anwendung ausgeführt wird, aber keine Fortschritte machen kann. Ein Neustart eines Containers in einem solchen Zustand kann dazu beitragen, dass die Anwendung trotz Fehlern besser verfügbar ist. Ja
readinessProbe Es ist wichtig, dass Sie einen Bereitschaftstest für Ihre Container haben. Auf diese Weise weiß der Kubelet-Prozess, der auf Ihrer Datenebene ausgeführt wird, wann der Container für den Datenverkehr bereit ist. 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 Balancers entfernt. Ja
startupProbe Das Kubelet verwendet Starttests, um zu erfahren, wann eine Containeranwendung gestartet wurde. Wenn ein solcher Test konfiguriert ist, werden die Verfügbarkeits- und Bereitschaftsprüfungen deaktiviert, 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, um zu verhindern, dass sie vom Kubelet zerstört werden, bevor sie betriebsbereit sind. Optional
podDisruptionBudget Definieren Sie ein Pod-Disruption-Budget (PDB), um sicherzustellen, dass eine Mindestanzahl von Pods auch bei freiwilligen Unterbrechungen PODS weiterläuft. A 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 niemals unter die für ein Quorum erforderliche Anzahl sinkt. Ein Web-Frontend möchte vielleicht sicherstellen, dass die Anzahl der Replikate, die die Last bedienen, niemals unter einen bestimmten Prozentsatz der Gesamtmenge 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 normalerweise für die IAM Funktion „Rollen für Dienstkonten“ verwendet Nein, die Rolle des IAM Servicekontos ARN ist in den EKS Amazon-Add-Ons auf oberster Ebene festgelegtAPI. Eine Ausnahme von dieser Regel ist, wenn Ihr Add-on über mehrere Bereitstellungen/Controller (wie Flux) verfügt und eine separate Rolle erfordert. IRSA ARNs
priorityClassName 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 auszuschließen (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 über eine Prioritätsklasse verfügen.
podSecurityContext Ein Sicherheitskontext definiert Einstellungen für Rechte und Zugriffskontrolle für einen Pod oder Container. Wird normalerweise zum Einstellen verwendet fsGroup — was IRSA in Version 1.19 und niedrigeren Clustern erforderlich war. Unwahrscheinlich, da Amazon Kubernetes v1.19 nicht EKS mehr unterstützt
securityContext Ein Sicherheitskontext definiert Einstellungen für Rechte und Zugriffskontrolle für einen Pod oder Container. Ja
updateStrategy Gibt die Strategie an, mit der alte Pods durch neue ersetzt werden. Ja
nameOverride Überschreibt den Namen der Pods. Nein
podSecurityPolicy

Erzwingen Sie Einschränkungen für Parameter.

 Nein — PSPs sind veraltet
extraVolumeMounts/extraVolumes

Wird IRSA in EKS Clustern außerhalb von Amazon verwendet.

Nein