View a markdown version of this page

Container-based requisiti di prodotto per Marketplace AWS - Marketplace AWS
Politiche per i venditori di prodotti containerPolicy di sicurezzaRequisiti in materia di informazioniRequisiti di utilizzo del prodottoRequisiti di architetturaRequisiti della struttura del grafico HelmIstruzioni per l'uso del prodotto ContainerRequisiti per i prodotti aggiuntivi Amazon EKS

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Container-based requisiti di prodotto per Marketplace AWS

Marketplace AWS mantiene i seguenti requisiti per tutti i prodotti e le offerte basati su container su. Marketplace AWS Questi requisiti aiutano a promuovere un catalogo sicuro e affidabile per i nostri clienti. Incoraggiamo inoltre i venditori a esaminare l'implementazione di controlli e protocolli aggiuntivi, se applicabili, per soddisfare le esigenze dei loro prodotti specifici.

Tutti i prodotti e i relativi metadati vengono esaminati al momento dell'invio per garantire che soddisfino o superino le politiche attuali Marketplace AWS . Queste politiche vengono aggiornate regolarmente per allinearsi alle linee guida di sicurezza in evoluzione. Marketplace AWS analizza continuamente i prodotti per verificare che le offerte esistenti continuino a soddisfare eventuali modifiche a questi requisiti. Se un prodotto non è conforme, Marketplace AWS contatterà il venditore per aggiornarlo e renderlo conforme ai nuovi standard. In alcuni casi, i prodotti potrebbero essere temporaneamente resi non disponibili per i nuovi abbonati fino alla risoluzione dei problemi. Questo processo aiuta a mantenere la sicurezza e l'affidabilità della Marketplace AWS piattaforma per tutti gli utenti.

Politiche per i venditori di prodotti container

In qualità di venditore di prodotti in container, devi rispettare le seguenti politiche:

  • Per impostazione predefinita, sei limitato a un massimo di 20 elenchi di prodotti in container pubblici. Se superi il limite, il tuo account è soggetto a una revisione periodica delle prestazioni e potrebbe esserti richiesto di limitare le offerte con prestazioni inferiori. Concediamo o revochiamo aumenti di questo limite a nostra esclusiva discrezione.

Policy di sicurezza

Tutti i prodotti basati su contenitori devono rispettare i seguenti requisiti di sicurezza:

  • Le immagini dei contenitori non devono contenere vulnerabilità, malware o pacchetti software End-of-Life (EoL) noti e sistemi operativi.

  • I contenitori non devono richiedere AWS credenziali per accedere ai servizi. AWS Quando il prodotto deve accedere ai AWS servizi, è necessario utilizzare uno dei seguenti:

    • Ruoli IAM per gli account di servizio, per i carichi di lavoro Amazon Elastic Kubernetes Service (Amazon EKS).

    • Ruoli IAM per le attività, per i carichi di lavoro di Amazon Elastic Container Service (Amazon ECS).

  • Container-based i prodotti devono richiedere solo i privilegi minimi per essere eseguiti. Per ulteriori informazioni, consulta Sicurezza in Amazon Elastic Container Service e Sicurezza in Amazon EKS.

  • Per impostazione predefinita, le immagini dei container devono essere configurate per essere eseguite con privilegi non root.

  • I contenitori non devono contenere segreti codificati come password (anche con hash) per utenti e servizi di sistema, chiavi private, credenziali, ecc.

  • L'autenticazione in tutti i servizi in esecuzione all'interno del contenitore non deve utilizzare l'autenticazione basata su password, anche se la password viene generata, reimpostata o definita dall'utente all'avvio. Inoltre, non sono consentite password vuote e nulle.

  • Le immagini dei contenitori non devono includere livelli con architetture non supportate (ad esempio, metadati completi di Attestation Framework).

Requisiti in materia di informazioni

Tutti i prodotti in container devono rispettare i seguenti requisiti in materia di informazioni per i clienti:

  • Il software non deve raccogliere o esportare i dati dei clienti all'insaputa e senza il consenso esplicito del cliente, ad eccezione di quanto richiesto dal BYOL (Bring Your Own License). Le applicazioni che raccolgono o esportano i dati dei clienti devono seguire queste linee guida:

    • La raccolta dei dati dei clienti deve essere self-service, automatizzata e sicura. Gli acquirenti non devono attendere che i venditori approvino l'implementazione del software.

    • La raccolta dei dati dei clienti deve essere conforme agli accordi stipulati con AWS, a titolo esemplificativo ma non esaustivo, i Termini e condizioni di AWS Marketplace, i Termini di AWS servizio, l'Informativa AWS sulla privacy e il Contratto con il AWS cliente.

    • Le informazioni di pagamento non devono essere raccolte.

Requisiti di utilizzo del prodotto

Tutti i prodotti in contenitori devono rispettare i seguenti requisiti di utilizzo del prodotto:

  • I venditori possono mettere in vendita solo prodotti perfettamente funzionanti. Non sono consentiti prodotti in versione beta o in versione provvisoria a scopo di prova o valutazione. Le edizioni per sviluppatori, community e BYOL del software commerciale sono supportate se il venditore fornisce una versione a pagamento equivalente Marketplace AWS entro 90 giorni dalla fornitura dell'edizione gratuita.

  • Tutte le istruzioni per l'uso di un prodotto basato su container devono includere tutti i passaggi per l'implementazione dei prodotti basati su container. Le istruzioni di utilizzo devono fornire comandi e risorse di distribuzione che rimandino alle immagini del contenitore corrispondenti. Marketplace AWS

  • Container-based i prodotti devono includere tutte le immagini dei contenitori necessarie a un abbonato per utilizzare il software. Inoltre, i prodotti basati su container non devono richiedere all'utente di avviare il prodotto utilizzando immagini provenienti dall'esterno Marketplace AWS (ad esempio, immagini di contenitori provenienti da archivi di terze parti).

  • I contenitori e il relativo software devono essere implementabili in modalità self-service e non devono richiedere metodi o costi di pagamento aggiuntivi. Le applicazioni che richiedono dipendenze esterne per l'implementazione devono seguire queste linee guida:

    • Il requisito deve essere indicato nella descrizione o nelle istruzioni d'uso dell'elenco. Ad esempio, questo prodotto richiede una connessione Internet per essere installato correttamente. <list of package>I seguenti pacchetti vengono scaricati durante la distribuzione:.

    • I venditori sono responsabili dell'uso e della garanzia della disponibilità e della sicurezza di tutte le dipendenze esterne.

    • Se le dipendenze esterne non sono più disponibili, è necessario rimuovere anche il prodotto. Marketplace AWS

    • Le dipendenze esterne non devono richiedere metodi o costi di pagamento aggiuntivi.

  • I contenitori che richiedono una connessione continua a risorse esterne non sotto il controllo diretto dell'acquirente, ad esempio API esterne o Servizi AWS gestite dal venditore o da una terza parte, devono seguire queste linee guida:

    • Il requisito deve essere indicato nella descrizione o nelle istruzioni per l'uso dell'inserzione. Ad esempio, questo prodotto richiede una connessione Internet continua. I seguenti servizi esterni continui sono necessari per funzionare correttamente:<list of resources>.

    • I venditori sono responsabili dell'uso e della garanzia della disponibilità e della sicurezza di tutte le risorse esterne.

    • Se le risorse esterne non sono più disponibili, è necessario rimuovere anche Marketplace AWS il prodotto.

    • Le risorse esterne non devono richiedere metodi o costi di pagamento aggiuntivi e la configurazione della connessione deve essere automatizzata.

  • Il software e i metadati del prodotto non devono contenere un linguaggio che reindirizzi gli utenti ad altre piattaforme cloud, prodotti aggiuntivi o servizi di upselling non disponibili su. Marketplace AWS

  • Se il prodotto è un componente aggiuntivo di un altro prodotto o di un altro ISV, la descrizione del prodotto deve indicare che estende le funzionalità dell'altro prodotto e che, senza di essa, il prodotto ha un'utilità molto limitata. Ad esempio, questo prodotto estende le funzionalità di <product name>questo prodotto e, senza di esso, ha un'utilità molto limitata. Tieni presente che <product name>potrebbe essere necessaria una licenza propria per la piena funzionalità di questo elenco.

Requisiti di architettura

Tutti i prodotti basati su container devono rispettare i seguenti requisiti di architettura:

  • Le immagini del contenitore di origine Marketplace AWS devono essere inviate al repository Amazon Elastic Container Registry (Amazon ECR) di proprietà di. Marketplace AWS Puoi creare questi repository nella Portale di gestione Marketplace AWS sezione dedicata ai prodotti server di ciascuno dei tuoi elenchi di prodotti container.

  • Le immagini dei container devono essere basate su Linux.

  • I prodotti a pagamento basati su container devono poter essere distribuiti su Amazon ECS, Amazon EKS o. AWS Fargate

  • I prodotti a pagamento basati su container con prezzi contrattuali e integrazione con AWS License Manager devono essere distribuiti su Amazon EKS, Amazon ECS, Amazon EKS Anywhere, Amazon ECS Anywhere AWS Fargate, Red Hat OpenShift Service on AWS (ROSA), cluster Kubernetes autogestiti in locale o su Amazon Elastic Compute Cloud.

  • Per i prodotti Helm Chart, i riferimenti alle immagini dei container devono essere strutturati in base al fine di supportare la distribuzione in più regioni. Requisiti della struttura del grafico Helm

  • Se il tuo prodotto basato su container richiede all'acquirente di distribuire un'Amazon Machine Image (AMI), deve essere un'AMI AWS gestita o un'AMI separata pubblicata in. Marketplace AWS Se pubblichi la tua AMI in Marketplace AWS, questa deve essere conforme alle AMI-based requisiti di prodotto per Marketplace AWS e devi indicare che si tratta di un prodotto aggiuntivo, come richiesto nel. Politiche di utilizzo del prodotto Puoi valutare il tuo AMI-based prodotto come BYOL perché è un'estensione della tua offerta basata su container. Marketplace AWS analizza i AMI-based prodotti alla ricerca di vulnerabilità ed esposizioni comuni (CVE) e requisiti di sicurezza privi di patch. I tuoi acquirenti devono inoltre abbonarsi al tuo prodotto prima di distribuirlo. AMI-based

Requisiti della struttura del grafico Helm

Tutti i prodotti Helm Chart inviati Marketplace AWS devono rispettare i seguenti requisiti di struttura per garantire una corretta regionalizzazione e distribuzione tra le regioni: AWS

  • I riferimenti alle immagini dei contenitori devono essere definiti esclusivamente nel values.yaml file e non codificati in nessun altro file all'interno del diagramma Helm. Ciò consente di Marketplace AWS sostituire automaticamente questi riferimenti durante la replica del prodotto in regioni diverse.

  • Il values.yaml file deve utilizzare variabili per tutti i riferimenti alle immagini dei contenitori.

  • Facoltativamente, puoi registry tag suddividerli in campi separati sullo stesso livello del repository per creare il riferimento dell'immagine.

  • I template Helm devono fare riferimento a queste variabili utilizzando la sintassi standard dei template Helm (ad es.). {{ .Values.image.repository }}:{{ .Values.image.tag }}

  • Evita di usare la logica condizionale nei modelli che bypasserebbe i riferimenti alle immagini definiti in. values.yaml

  • Quando testate il grafico Helm con AWS regioni diverse, assicuratevi che modificando values.yaml correttamente la regione si aggiornino tutti i riferimenti alle immagini nelle risorse distribuite.

Marketplace AWS verifica che tutti i riferimenti alle immagini dei contenitori siano definiti correttamente nel values.yaml file durante il processo di invio del prodotto. I prodotti che non soddisfano questi requisiti verranno rifiutati.

Requisiti per i riferimenti alle immagini dei contenitori nei grafici Helm

Di seguito vengono illustrati gli approcci per strutturare i riferimenti alle immagini dei contenitori nei grafici Helm:

values.yaml(formato consigliato): 

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

Consigliamo l'approccio precedente per la struttura del tuovalues.yaml, ma sono validi anche i metodi alternativi seguenti.

values.yaml(formato alternativo): 

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

values.yaml(formato alternativo): 

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

Per il modello di distribuzione, il formato seguente è l'unico formato valido disponibile.

Modello di distribuzione: 

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

Approccio errato (non utilizzare): 

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

Possibili errori di convalida del diagramma Helm

Durante il processo di invio del prodotto, Marketplace AWS esegue controlli di convalida sui prodotti Helm Chart per garantire la conformità ai requisiti di riferimento delle immagini dei contenitori. Se il diagramma Helm non soddisfa questi requisiti, è possibile che si verifichino i seguenti errori di convalida:

Errore Spiegazione
INCOMPATIBLE_HELM_OBJECTS Gli oggetti Helm specificati non sono supportati per i componenti aggiuntivi EKS. Consulta Requisiti per i prodotti aggiuntivi Amazon EKS.
INVALID_DEPENDENT_HELM_CHARTS I grafici Helm dipendenti devono essere contenuti nella directory principale del grafico e non devono essere di origine esterna.
INVALID_HELM_SENSITIVE_CONFIG Lo schema di configurazione non può contenere campi che raccolgono informazioni sensibili. Gli schemi di configurazione non devono accettare password, chiavi API, certificati o segreti. Fornisci invece campi per i nomi segreti di Kubernetes che i clienti creeranno separatamente.
INVALID_HELM_CHART_IMAGES Tutte le immagini, comprese le dipendenze open source, devono essere inviate ai repository Marketplace AWS Amazon ECR creati tramite la richiesta Add Repository. Fase 1: Aggiungere repository
INVALID_HELM_UNDECLARED_IMAGES Tutti i riferimenti alle immagini del contenitore devono essere elencati in modo esplicito nella richiesta di aggiunta della versione. Fase 3: aggiungi una nuova versione al tuo prodotto contenitore
INVALID_HELM_LINT La convalida del diagramma Helm non è riuscitahelm lint. Esegui helm lint localmente per identificare e risolvere problemi strutturali o sintattici. Usa la versione 3.19.0 Helm o successiva.
INVALID_HELM_TEMPLATE La convalida del diagramma Helm non è riuscitahelm template. Il grafico non può essere renderizzato in manifesti Kubernetes validi. Esegui il test localmente con helm template per identificare gli errori logici o di sintassi del modello. Usa la versione Helm 3.19.0 o successiva.
MISSING_HELM_DEPLOYMENT_CONFIG Il diagramma Helm per un componente aggiuntivo Amazon EKS deve contenere una distribuzione o una risorsa. DaemonSet Amazon EKS richiede almeno uno di questi tipi di carico di lavoro per la gestione del ciclo di vita dei componenti aggiuntivi. Consulta Requisiti per i prodotti aggiuntivi Amazon EKS.
INCOMPATIBLE_CONFIGURATION_SCHEMA_VERSION La versione dello schema JSON in non è supportata. aws_mp_configuration_schema.json Vedi Requisiti dello schema le versioni dello schema supportate.
INVALID_IMAGE_REFERENCE Tutte le immagini devono essere definite come variabili values.yaml e referenziate utilizzando la sintassi del modello Helm, come descritto in. Requisiti della struttura del grafico Helm
MISSING_VALUES_IMAGE_REFERENCE Ogni riferimento all'immagine del contenitore deve avere una voce corrispondente in. values.yaml
MISSING_IMAGE_TAG I riferimenti alle immagini del contenitore in values.yaml devono includere valori di tag espliciti o devono corrispondere per impostazione predefinita alla versione del grafico di Chart.yaml origine.

Istruzioni per l'uso del prodotto Container

Quando crei le istruzioni per l'uso del prodotto in contenitore, segui i passaggi e le indicazioni inCreazione di AMI e istruzioni per l'uso dei prodotti in container per Marketplace AWS.

Istruzioni per l'uso di Helm Chart

Durante la creazione di istruzioni per l'uso dei prodotti Helm Chart:

  • Documenta in modo chiaro tutti i parametri configurabili nel tuo values.yaml file, inclusi i parametri del repository di immagini, dei tag e del registro.

  • Fornisci esempi di come sovrascrivere questi parametri durante l'installazione del grafico Helm.

  • Non chiedere agli utenti di modificare file diversi da quelli utilizzati values.yaml o di utilizzare --set parametri durante l'installazione del grafico.

  • Includi informazioni su come il tuo prodotto gestisce la regionalizzazione delle immagini dei contenitori.

Requisiti per i prodotti aggiuntivi Amazon EKS

Un componente aggiuntivo Amazon EKS è un software che fornisce funzionalità operative alle Kubernetes applicazioni ma non è specifico per l'applicazione. Ad esempio, un componente aggiuntivo di Amazon EKS include agenti o Kubernetes driver di osservabilità che consentono al cluster di interagire con AWS le risorse sottostanti per il networking, l'elaborazione e lo storage.

In qualità di venditore di prodotti container, puoi scegliere tra diverse opzioni di distribuzione, tra cui Amazon EKS. Puoi pubblicare una versione del tuo prodotto come componente aggiuntivo nel catalogo dei Marketplace AWS componenti aggiuntivi di Amazon EKS. Il componente aggiuntivo viene visualizzato nella console di Amazon EKS accanto ai componenti aggiuntivi gestiti da e da AWS altri fornitori. I tuoi acquirenti possono implementare il tuo software come componente aggiuntivo con la stessa facilità con cui utilizzano gli altri componenti aggiuntivi.

Per ulteriori informazioni, consulta Componenti aggiuntivi di Amazon EKS nella Guida per l'utente di Amazon EKS.

Preparare il prodotto in contenitore come Marketplace AWS componente aggiuntivo

Per pubblicare il prodotto contenitore come Marketplace AWS componente aggiuntivo, deve soddisfare i seguenti requisiti:

  • Il prodotto contenitore deve essere pubblicato in Marketplace AWS.

  • Il prodotto contenitore deve essere progettato per essere compatibile con le architetture AMD64 e ARM64.

  • Il prodotto contenitore non deve utilizzare il modello di prezzo Bring Your Own License (BYOL). https://docs.aws.amazon.com/marketplace/latest/userguide/pricing-container-products.html

    Nota

    Il BYOL non è supportato per la consegna del componente aggiuntivo Amazon EKS.

  • È necessario rispettare tutti i requisiti di prodotto basati sui container, incluso l'inserimento di tutte le immagini e i Helm grafici dei contenitori nei repository gestiti di Amazon ECR. Marketplace AWS Questo requisito include, ad esempio, immagini open source. nginx Immagini e grafici non possono essere ospitati in altri repository esterni, tra cui, a titolo esemplificativo, Amazon ECR Public Gallery e. Docker Hub Quay

  • Helmgrafici: prepara e impacchetta il tuo software come grafico. Helm Il framework aggiuntivo Amazon EKS converte un Helm grafico in un manifest Kubernetes. Alcune Helm funzionalità non sono supportate nei sistemi Amazon EKS. L'elenco seguente descrive i requisiti che devono essere soddisfatti prima dell'onboarding del software come componente aggiuntivo di Amazon EKS. In questo elenco, tutti i Helm comandi utilizzano la Helm versione 3.19.0:

    • Tutti Capabilities gli oggetti sono supportati, ad eccezione di. .APIVersions .APIVersionsnon è supportato per le Kubernetes API personalizzate non integrate.

    • Sono supportati solo gli Release.Namespace oggetti Release.Name and.

    • Helmgli hook e la lookup funzione non sono supportati.

    • Tutti i grafici dipendenti devono trovarsi all'interno del Helm grafico principale (specificato nel file di percorso del repository://...).

    • Il Helm grafico deve superare correttamente Helm Lint e Helm Template senza errori. I comandi sono i seguenti:

      • HelmLanugine — helm lint helm-chart

        I problemi più comuni includono i grafici non dichiarati nei metadati del grafico principale. Ad esempio, chart metadata is missing these dependencies: chart-base Error: 1 chart(s) linted, 1 chart(s) failed

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

        Passa tutte le configurazioni sovrascritte con il flag. -f

    • Archivia tutti i file binari dei contenitori nei Marketplace AWS repository Amazon ECR. Per creare un manifest, usa il comando Helm template mostrato in precedenza. Cerca nel manifesto eventuali riferimenti a immagini esterne, ad esempio gcr immagini busybox o immagini. Carica tutte le immagini dei contenitori insieme alle dipendenze nei repository Marketplace AWS Amazon ECR creati utilizzando l'opzione Aggiungi repository nel menu a discesa delle richieste.

  • Configurazione personalizzata: puoi aggiungere variabili personalizzate durante la distribuzione. Per informazioni su come identificare l'esperienza dell'utente finale, assegnare un nome al software aws_mp_configuration_schema.json e raggrupparlo in un involucro con il Helm grafico, consulta i componenti aggiuntivi di Amazon EKS: configurazione avanzata.

    Secondo la parola chiave «$schema», $schema deve essere un URI che punta a una risorsa valida. application/schema+json

    Questo file non deve accettare informazioni sensibili come password, chiavi di licenza e certificati.

    Per gestire le installazioni segrete e dei certificati, puoi fornire passaggi successivi o preliminari all'Add-on installazione agli utenti finali. Il prodotto non deve fare affidamento su licenze esterne. Il prodotto dovrebbe funzionare in base ai Marketplace AWS diritti.

    Per ulteriori informazioni sulle limitazioni peraws_mp_configuration_schema.json, vedere. Add-on requisiti di configurazione e best practice per i fornitori di componenti aggiuntivi

  • Identifica e crea lo spazio dei nomi in cui verrà distribuito il software: nella prima versione del prodotto, devi identificare lo spazio dei nomi in cui verrà distribuito il software aggiungendo uno spazio dei nomi basato su modelli.

  • Definizioni di risorse personalizzate (CRD): il framework aggiuntivo Amazon EKS non supporta l'installazione di CRD e dichiarazioni di risorse personalizzate basate su CRD applicate con lo stesso componente aggiuntivo. Se il componente aggiuntivo dispone di risorse personalizzate e si basa su CRD, puoi:

    • Pubblica due componenti aggiuntivi: suddividi la definizione CRD in un componente aggiuntivo separato (grafico a parte) e l'effettiva installazione delle risorse personalizzate in un componente aggiuntivo separato.

    • Pubblica un singolo componente aggiuntivo con istruzioni manuali aggiuntive: pubblica un singolo componente aggiuntivo che installa i CRD sul cluster. Fornisci istruzioni per l'uso insieme ai file manifest di Kubernetes per consentire agli utenti finali di configurare risorse personalizzate che dipendono da tali CRD.

  • Crea il, serviceAccount se applicabile: se il software è a pagamento Marketplace AWS o deve connettersi ad altri Servizi AWS, assicurati che il Helm grafico venga creato per impostazione predefinita. serviceAccount Se la serviceAccount creazione è gestita da un parametro in un values.yaml file, imposta il valore del parametro su. true Ad esempio, serviceAccount.create = true. Ciò è necessario perché il cliente potrebbe scegliere di installare il componente aggiuntivo ereditando le autorizzazioni dall'istanza del nodo sottostante che dispone già delle autorizzazioni richieste. Se il grafico Helm non crea ilserviceAccount, le autorizzazioni non possono essere collegate a. serviceAccount

  • Distribuzioni o set di daemonset tracciabili: assicurati che il tuo diagramma Helm abbia un daemonset o una distribuzione. Il framework aggiuntivo Amazon EKS monitora l'implementazione delle tue risorse Amazon EKS utilizzandole. Senza una distribuzione o un daemonset tracciabili, il tuo addon subirà un errore di distribuzione. Se il tuo addon non ha una distribuzione o un daemonset, ad esempio, se il tuo addon distribuisce una serie di risorse personalizzate o un job Kubernetes che non sono tracciabili, aggiungi una distribuzione o un oggetto daemonset fittizio.

  • Supporto per architetture AMD e ARM: molti clienti Amazon EKS utilizzano oggi ARM64 per utilizzare le istanze Graviton. AWS Third-party il software deve supportare entrambe le architetture.

  • Si integra con le API di licenza o misurazione di Marketplace AWS: Marketplace AWS supporta più modelli di fatturazione. Per ulteriori informazioni, consulta Integrazioni di fatturazione, misurazione e licenza dei prodotti container. Se desideri vendere il tuo prodotto tramite i meccanismi PAYG, consulta. Configurazione di contatori personalizzati per prodotti container con AWS Marketplace Metering Service Se desideri vendere il tuo prodotto tramite un modello anticipato o contrattuale, consulta. Prezzi contrattuali per prodotti in container con AWS License Manager

  • Carica il software e tutti gli artefatti e le dipendenze: il grafico Helm deve essere autonomo e non deve richiedere dipendenze da fonti esterne, ad esempio. GitHub Se il software richiede dipendenze esterne, le dipendenze devono essere inviate a repository privati di Amazon ECR con lo stesso elenco. Marketplace AWS Marketplace AWS

  • Fornisci istruzioni di distribuzione sul tuo sito web: ti chiediamo di pubblicare una guida all'implementazione per i clienti per identificare come distribuire il tuo software tramite il comando create-addon. https://docs.aws.amazon.com/cli/latest/reference/eks/create-addon.html

  • Add-on permissions/IAM ruoli: se il componente aggiuntivo pubblicato da Marketplace AWS richiede l'accesso a un AWS servizio, il software dovrebbe avere un account di servizio Kubernetes annotato con le politiche IAM per accedere ai servizi. AWS Puoi scegliere tra due opzioni per il tuo account di servizio per effettuare richieste API ai AWS servizi:

    Il componente aggiuntivo deve avere un file di configurazione aggiuntivo denominato aws_mp_addon_parameters.json nel livello superiore del grafico Helm, nella stessa directory dello schema di configurazione personalizzato corrente (). aws_mp_configuration_schema.json Attualmente, questo file gestisce solo le autorizzazioni compatibili con l'identità dei pod. Il formato del file è il seguente: 

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

    Nome del file: aws_mp_addon_parameters.json

    Nota

    Il aws_mp_addon_parameters.json file abilita la sezione di Add-on accesso nella pagina delle impostazioni di Add-on configurazione della console Amazon EKS

    Nome del campo Tipo Note Valore di esempio
    è PodIdentityCompatible Booleano Per ora è supportato solo `true`. Il campo mostra se le autorizzazioni descritte nel seguente elenco PermissionsList corrispondono a pod-identity TRUE
    Account di servizio Stringa Il nome dell'account di servizio che il componente aggiuntivo utilizzerà per accedere alle autorizzazioni kpow
    Politiche gestite Elenco <String> Elenco degli avvisi di policy da utilizzare per questo account di servizio che possono essere utilizzati dal componente aggiuntivo EKS ["arn:aws:iam::aws:policy/ReadOnlyAccess"]
    Nota

    Pay-as-you-go I prodotti aggiuntivi (PAYG) di Amazon EKS Pod Identity non Marketplace AWS possono utilizzare Amazon EKS Pod Identity e devono utilizzare IAM Roles for Service Accounts (IRSA) per il controllo degli accessi.

  • Aggiornamenti delle versioni: Amazon EKS rilascia nuove versioni di Kubernetes poche settimane dopo il rilascio upstream. Man mano che le nuove versioni del cluster Amazon EKS diventano generalmente disponibili, i fornitori hanno 45 giorni per certificare o aggiornare il loro software in modo che sia compatibile con la nuova versione del cluster Amazon EKS. Se le versioni attuali del componente aggiuntivo supportano la nuova versione di Kubernetes, convalida e certifica la stessa in modo da poter aggiornare la matrice di compatibilità delle versioni. Se è necessaria una nuova versione del componente aggiuntivo per supportare la nuova versione di Kubernetes, invia la nuova versione per l'onboarding.

  • Il software del partner deve rientrare in uno dei seguenti tipi o essere un software operativo che migliorerà Kubernetes o Amazon EKS: Gitops | monitoring | logging | cert-management | gestione delle policy | gestione dei costi | scalabilità automatica | storage | gestione kubernetes | service-mesh | etcd-backup | ingress-service-type | load-balancer | locregistral-y| networking | Security | backup | ingress-service-type | load-balancer | locregistral-y| networking | Sicurezza | backup | ingress-service type controllore | osservabilità

  • Il software non può essere Container Network Interface (CNI).

  • Il software deve essere venduto Marketplace AWS e integrato con le API di licenza e misurazione per i prodotti a pagamento. I prodotti BYOL non sono accettati.

Add-on requisiti di configurazione e best practice per i fornitori di componenti aggiuntivi

Amazon EKS richiede la configurazione come stringa di schema JSON Helm dai fornitori di componenti aggiuntivi. Add-ons che richiedono configurazioni obbligatorie o consentono configurazioni opzionali devono includere un aws_mp_configuration_schema.json file con l'Helm Chart inviato a. Marketplace AWS Amazon EKS utilizzerà questo schema per convalidare l'input di configurazione dei clienti e rifiutare le chiamate API con valori di input non conformi allo schema. Add-on le configurazioni rientrano in genere in due categorie:

  • Configurazione per proprietà generali di Kubernetes come etichette, tolleranze, NodeSelector, ecc.

  • Configurazioni specifiche per i componenti aggiuntivi come chiave di licenza, attivazione delle funzionalità, URL, ecc.

Questa sezione è incentrata sulla prima categoria relativa alle proprietà generali di Kubernetes.

Amazon EKS consiglia di seguire le best practice relative alla configurazione dei componenti aggiuntivi di Amazon EKS.

Requisiti dello schema

Quando definisci lo schema json, assicurati di utilizzare una versione di jsonschema supportata dai componenti aggiuntivi di Amazon EKS.

L'elenco degli schemi supportati:

  • 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

L'utilizzo di qualsiasi altra versione dello schema json è incompatibile con i componenti aggiuntivi di Amazon EKS e impedirà il rilascio del componente aggiuntivo finché il problema non verrà risolto.

Esempio di file di schema Helm 

{
"$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

I parametri di configurazione devono essere CamelCase e verranno rifiutati se non aderiscono a questo formato.

Le descrizioni sono obbligatorie

Includi sempre descrizioni significative per le proprietà dello schema. Questa descrizione verrà utilizzata per visualizzare i nomi delle etichette nella console Amazon EKS per ciascun parametro di configurazione.

Definizione RBAC

Add-on i provider devono definire e fornire le autorizzazioni RBAC necessarie per installare correttamente il componente aggiuntivo utilizzando il principio del privilegio minimo. Se è necessario modificare le autorizzazioni RBAC per le versioni più recenti del componente aggiuntivo o apportare correzioni per risolvere un CVE, i fornitori di componenti aggiuntivi dovranno informare il team di Amazon EKS in merito a tale modifica. Le autorizzazioni richieste per ogni risorsa Kubernetes devono essere limitate al nome della risorsa dell'oggetto. 

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

Questa sezione si applica solo ai componenti aggiuntivi che richiedono ai clienti di configurare informazioni segrete come chiave applicativa, chiave API, password, ecc. Attualmente, le API Amazon EKS non supportano il trasferimento di informazioni segrete in testo normale a causa delle implicazioni di sicurezza. Tuttavia, i clienti possono utilizzare la configurazione per passare il nome del segreto Kubernetes che contiene le chiavi necessarie al componente aggiuntivo. Ai clienti verrà richiesto di creare oggetti Kubernetes Secret contenenti le chiavi con lo stesso namespace come passaggio preliminare e quindi di passare il nome del segreto utilizzando il blob di configurazione durante la creazione del componente aggiuntivo. Consigliamo ai provider di componenti aggiuntivi di denominare le proprietà dello schema in modo che i clienti non lo scambino accidentalmente con la chiave effettiva. Ad esempio: appSecretName, connessione ecc. SecretName

In sintesi, i fornitori di componenti aggiuntivi possono utilizzare lo schema per consentire ai clienti di passare il nome del segreto ma non le chiavi che effettivamente conterranno il segreto stesso.

Valori di configurazione di esempio

Puoi includere esempi di configurazione nello schema per aiutare i clienti nella configurazione dei componenti aggiuntivi. L'esempio seguente è tratto dallo schema di 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": []
      }
    ]

Parametri comuni consentiti per la configurazione

I seguenti sono i parametri consigliati in un file di schema Helm rivolto al cliente.

Parametro Description Dovrebbe avere un valore predefinito?
Etichette aggiuntive Aggiungi etichette Kubernetes a tutti gli oggetti Kubernetes gestiti dal componente aggiuntivo. No
Annotazioni aggiuntive Aggiungi annotazioni Kubernetes a tutti gli oggetti Kubernetes gestiti dal componente aggiuntivo. No
Etichette POD Aggiungi etichette Kubernetes ai pod gestiti dal componente aggiuntivo. No
Annotazioni POD Aggiungi annotazioni Kubernetes ai pod gestiti dal componente aggiuntivo. No
logLevel Livello di registro per i componenti gestiti dal componente aggiuntivo. Sì
nodeSelector La forma più semplice consigliata di vincolo di selezione dei nodi. Puoi aggiungere il campo NodeSelector alle specifiche del tuo Pod e specificare le etichette dei nodi che desideri che il nodo di destinazione abbia. Potenzialmente, ad esempio, solo nodi Linux
tolleranze Le tolleranze vengono applicate ai pod. Le tolleranze consentono allo scheduler di programmare i pod con i valori corrispondenti. Le tolleranze consentono la programmazione ma non garantiscono la pianificazione. Forse, più comune con i daemonset
affinità La funzionalità di affinità è costituita da due tipi di affinità: Node affinity funziona come il campo NodeSelector ma è più espressiva e consente di specificare regole soft, Inter-pod affinity/anti -affinity consente di vincolare i Pod alle etichette presenti su altri Pod. Probabile
topologia SpreadConstraints È possibile utilizzare i vincoli di diffusione della topologia per controllare la distribuzione dei pod nel cluster tra domini di errore come regioni, zone, nodi e altri domini di topologia definiti dall'utente. Questo può aiutare a raggiungere un'elevata disponibilità e un utilizzo efficiente delle risorse. Probabile
risorsa request/limits Specifica la quantità necessaria per cpu/memory ogni contenitore. Si consiglia vivamente di impostare le richieste. I limiti sono opzionali. Sì
replicas Numero di repliche dei pod gestiti dal componente aggiuntivo. Non applicabile ai daemonset. Sì
Nota

Per i parametri di configurazione della pianificazione del carico di lavoro, potrebbe essere necessario separare i componenti di primo livello nello schema, ove necessario. Ad esempio, il driver CSI di Amazon EBS contiene due componenti principali, controller e node agent: i clienti richiedono un nodo selectors/tolerations diverso per ogni componente.

Nota

I valori predefiniti definiti nello schema JSON sono puramente a scopo di documentazione per l'utente e non sostituiscono la necessità di avere il valore predefinito corretto nel file. values.yaml Se utilizzi la proprietà predefinita, assicurati che l'impostazione predefinita values.yaml corrisponda a quella nello schema e i due elementi (values.schema.jsonevalues.yaml) rimangano sincronizzati ogni volta che vengono apportate modifiche allo Helm Chart.

"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"
            ]
          }

Parametri comuni che non sono consentiti per la configurazione

Parametri di metadati del cluster come clusterNameregion, vpcIdaccountId, e altri possono essere richiesti da vari componenti aggiuntivi (ad esempio, Elastic Load Balancing Controller). Qualsiasi parametro simile a questi noto al servizio Amazon EKS verrà inserito automaticamente dai componenti aggiuntivi di Amazon EKS e non sarà responsabilità dell'utente specificarlo come opzione di configurazione. Questi parametri includono:

  • AWS regione

  • nome del cluster Amazon EKS

  • ID VPC del cluster

  • Registro dei contenitori, specifico per gli account build-prod, utilizzato dai componenti aggiuntivi di rete

  • IP del cluster DNS, specifico per il componente aggiuntivo corendns

  • Endpoint API del cluster Amazon EKS

  • IPv4 abilitato sul cluster

  • IPv6 abilitato sul cluster

  • La delega del prefisso per IPv6 è abilitata nel cluster

Add-on i provider devono assicurarsi che siano definiti i modelli per tali parametri applicabili. Ciascuno dei parametri precedenti avrà un parameterType attributo predefinito definito da Amazon EKS. I metadati di rilascio specificheranno la mappatura tra il parameterType e il name/path parametro nel modello. In questo modo, i valori possono essere trasmessi dinamicamente da Amazon EKS senza richiedere ai clienti di specificarli tramite configurazioni e offre inoltre la flessibilità ai fornitori di componenti aggiuntivi per definire il proprio modello. name/path I parametri come quelli precedenti che Amazon EKS deve iniettare dinamicamente devono essere esclusi dal file di schema.

Esempio di mappatura dai metadati di rilascio 

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

Di seguito sono riportati i parametri che non è consigliabile configurare in un file di schema Helm rivolto al cliente. O i parametri devono avere valori predefiniti non modificabili o non essere inclusi affatto nel modello aggiuntivo.

Parametro Description Dovrebbe avere un valore predefinito?
image Immagine del contenitore che verrà distribuita nel cluster Kubernetes. No, gestito tramite una definizione aggiuntiva
immagine PullSecrets Configurazione di un pod per utilizzare un segreto da estrarre da un registro privato. N/A
Sonda LiveNess Il processo Kubelet utilizza le sonde liveness per sapere quando riavviare un container. Ad esempio, le sonde liveness potrebbero rilevare un punto morto, quando un'applicazione è in esecuzione ma non è in grado di progredire. Il riavvio di un contenitore in tale stato può contribuire a rendere l'applicazione più disponibile nonostante i bug. Sì
Sonda Readiness È importante disporre di una sonda di prontezza per i contenitori. In questo modo il processo Kubelet in esecuzione sul piano dati saprà quando il contenitore è pronto per servire il traffico. Un Pod è considerato pronto quando tutti i suoi contenitori sono pronti. Un utilizzo di questo segnale è controllare quali Pod vengono utilizzati come backend per i Servizi. Quando un Pod non è pronto, viene rimosso dai service load balancer. Sì
Sonda di avvio Il kubelet utilizza le sonde di avvio per sapere quando un'applicazione contenitore è stata avviata. Se una sonda di questo tipo è configurata, disattiva i controlli di operatività e disponibilità finché non ha esito positivo, assicurandosi che tali sonde non interferiscano con l'avvio dell'applicazione. Questo può essere usato per adottare controlli di vivacità sui container ad avvio lento, evitando che vengano eliminati dal kubelet prima che siano attivi e funzionanti. Facoltativo
cialda DisruptionBudget Definisci un Pod Discruption Budget (PDB) per garantire che un numero minimo di POD continui a funzionare durante le interruzioni volontarie. Un PDB limita il numero di Pod di un'applicazione replicata che sono inattivi contemporaneamente a causa di interruzioni volontarie. Ad esempio, un'applicazione basata sul quorum vorrebbe garantire che il numero di repliche in esecuzione non venga mai portato al di sotto del numero necessario per il raggiungimento del quorum. Un front-end web potrebbe voler garantire che il numero di repliche che servono il carico non scenda mai al di sotto di una certa percentuale del totale. Sì, se il valore predefinito è impostato su più di due repliche
Service Account (nome) Nome dell'account di servizio con cui verranno eseguiti i pod. Sì
ServiceAccount (annotazioni) Annotazioni applicate all'account del servizio. Utilizzato in genere per la funzionalità IAM Roles for Service Accounts No, il ruolo ARN dell'account di servizio IAM è impostato nell'API dei componenti aggiuntivi di Amazon EKS di primo livello. Un'eccezione a questa regola si verifica se il componente aggiuntivo ne ha più deployments/controllers (come Flux) e richiede ARN con ruoli IRSA separati.
priorità ClassName La priorità indica l'importanza di un Pod rispetto agli altri Pod. Se un Pod non può essere programmato, lo scheduler tenta di anticipare (sfrattare) i Pod con priorità inferiore per rendere possibile la pianificazione del Pod in sospeso. Sì. La maggior parte dei componenti aggiuntivi è fondamentale per la funzionalità del cluster e dovrebbe avere una classe di priorità impostata di default.
pod SecurityContext Un contesto di sicurezza definisce le impostazioni dei privilegi e del controllo degli accessi per un pod o un container. In genere utilizzato per impostare FSGroup, richiesto per IRSA nella versione 1.19 e nei cluster precedenti. Improbabile, dato che Amazon EKS non supporta più Kubernetes v1.19
Contesto di sicurezza Un contesto di sicurezza definisce le impostazioni dei privilegi e del controllo degli accessi per un pod o un container. Sì
Strategia di aggiornamento Specifica la strategia utilizzata per sostituire i vecchi pod con altri nuovi. Sì
NameOverride Sostituisci il nome dei pod. No
pod SecurityPolicy

Applica le restrizioni sui parametri.

 No, i PSP sono obsoleti
extraVolumeMounts/extraVolumes

Utilizzato per IRSA in cluster non Amazon EKS.

No