Requisiti di prodotto basati su container per Marketplace AWS - Marketplace AWS
Requisiti in materia di sicurezzaRequisiti di accesso Requisiti in materia di informazioniRequisiti di utilizzo del prodottoRequisiti di architetturaIstruzioni per l'uso del prodotto ContainerRequisiti per i EKS prodotti aggiuntivi Amazon

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à.

Requisiti di prodotto basati su container per Marketplace AWS

Marketplace AWS mantiene i seguenti requisiti per tutti i prodotti e le offerte basati su container. Marketplace AWS Questi requisiti aiutano a promuovere un catalogo sicuro e affidabile per i nostri clienti. Incoraggiamo inoltre i venditori a verificare 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 una volta inviati per garantire che soddisfino o superino i requisiti attuali Marketplace AWS . Esaminiamo e modifichiamo queste politiche per soddisfare i nostri requisiti di sicurezza e altri requisiti di utilizzo in continua evoluzione. Marketplace AWS verifica continuamente che i prodotti esistenti continuino a soddisfare eventuali modifiche a questi requisiti. Se i prodotti non sono conformi, ti Marketplace AWS contatteremo per aggiornarlo. In alcuni casi, il prodotto potrebbe essere temporaneamente non disponibile per i nuovi abbonati fino alla risoluzione dei problemi.

Requisiti in materia di sicurezza

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

  • Le immagini dei container Docker devono essere prive di malware, virus o vulnerabilità noti. Quando aggiungi una nuova versione al tuo prodotto container, le immagini del contenitore incluse nella versione vengono scansionate.

  • Se i tuoi prodotti basati su container richiedono l'accesso per gestire AWS le risorse, l'accesso deve essere ottenuto tramite IAMruoli per account di servizio (se eseguiti tramite Amazon Elastic Kubernetes Service EKS (Amazon IAM)) o ruoli per le attività (se eseguiti tramite Amazon Elastic Container Service ECS (Amazon)) anziché richiedere una chiave di accesso agli utenti.

  • I prodotti basati su container devono richiedere solo i privilegi minimi per essere eseguiti. Per ulteriori informazioni, consulta ECSSicurezza e protezione. EKS

  • Per impostazione predefinita, le immagini dei contenitori devono essere configurate per l'esecuzione con privilegi non root.

Requisiti di accesso

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

  • I prodotti basati su container devono utilizzare una password iniziale casuale. I prodotti basati su container non devono utilizzare password iniziali fisse o vuote per l'accesso amministrativo esterno (ad esempio, per accedere all'applicazione tramite un'interfaccia Web). È necessario che all'acquirente venga richiesta questa password casuale prima di poter impostare o modificare le proprie credenziali.

  • Qualsiasi accesso esterno all'applicazione deve essere esplicitamente accettato e abilitato dai clienti.

Requisiti in materia di informazioni

Tutti i prodotti basati su contenitori devono rispettare i seguenti requisiti in materia di informazioni per i clienti:

  • Il software non deve raccogliere o esportare i dati dei clienti a insaputa del cliente e senza il suo consenso esplicito, ad eccezione di quanto richiesto da 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.

    • I requisiti relativi ai dati dei clienti devono essere chiaramente indicati nella descrizione o nelle istruzioni d'uso dell'inserzione. Ciò include ciò che viene raccolto, il luogo in cui verranno archiviati i dati del cliente e il modo in cui verranno utilizzati. Ad esempio, questo prodotto raccoglie il tuo nome e indirizzo email. <company name>Queste informazioni vengono inviate e archiviate da. Queste informazioni verranno utilizzate solo per contattare l'acquirente in merito a. <product name>

    • Le informazioni di pagamento non devono essere raccolte.

Requisiti di utilizzo del prodotto

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

  • I venditori possono pubblicare solo prodotti perfettamente funzionanti. Non sono ammessi prodotti beta o in versione preliminare a scopo di prova o valutazione. BYOLLe edizioni per sviluppatori, community e commerciali del software commerciale sono supportate se il venditore fornisce una versione equivalente a pagamento 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 la distribuzione di prodotti basati su contenitori. Le istruzioni di utilizzo devono fornire comandi e risorse di distribuzione che puntino alle immagini del contenitore corrispondenti su. Marketplace AWS

  • I prodotti basati su container devono includere tutte le immagini dei container di cui un abbonato ha bisogno per utilizzare il software. Inoltre, i prodotti basati su container non devono richiedere all'utente di avviare il prodotto utilizzando immagini esterne Marketplace AWS (ad esempio, immagini di contenitori provenienti da repository di terze parti).

  • I container 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 la distribuzione 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 distribuito correttamente. I seguenti pacchetti vengono scaricati durante la distribuzione:. <list of package>

    • 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 da 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 esterne APIs 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 d'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 reindirizza 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 del prodotto ISV di un altro, la descrizione del prodotto deve indicare che estende le funzionalità dell'altro prodotto e che senza di essa l'utilità del prodotto è molto limitata. Ad esempio, questo prodotto estende le funzionalità di e senza di esso, ha un'utilità molto limitata<product name>. Tieni presente che potrebbe essere necessaria una licenza propria per la piena funzionalità di questo elenco. <product name>

Requisiti di architettura

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

  • Le immagini del contenitore di origine per Marketplace AWS devono essere inviate al repository Amazon Elastic Container Registry (AmazonECR) di proprietà di. Marketplace AWS Puoi creare questi repository nei prodotti Portale di gestione Marketplace AWS sotto server per ciascuno dei tuoi elenchi di prodotti in 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 un'integrazione con AWS License Manager devono essere distribuiti su Amazon, Amazon, EKS Amazon AnywhereECS, AWS Fargate Amazon ECS AnywhereEKS, Red Hat OpenShift Service on AWS (ROSA), cluster Kubernetes autogestiti in locale o su Amazon Elastic Compute Cloud.

Istruzioni per l'uso del prodotto Container

Quando crei le istruzioni per l'uso del tuo prodotto in contenitore, segui i passaggi e le istruzioni riportate inCreazione AMI e contenitore di istruzioni per l'uso del prodotto per Marketplace AWS.

Requisiti per i EKS prodotti aggiuntivi Amazon

Un EKS componente aggiuntivo di Amazon è un software che fornisce funzionalità operative per Kubernetes applicazioni ma non è specifico per l'applicazione. Ad esempio, un EKS componente aggiuntivo di Amazon include agenti di osservabilità o Kubernetes driver 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 implementazione, tra cui AmazonEKS. Puoi pubblicare una versione del tuo prodotto come Marketplace AWS componente aggiuntivo nel catalogo dei componenti EKS aggiuntivi di Amazon. Il tuo componente aggiuntivo viene visualizzato nella EKS console Amazon accanto ai componenti aggiuntivi gestiti da AWS e da 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 EKSi componenti aggiuntivi di Amazon nella Amazon EKS User Guide.

Preparazione del prodotto in contenitore come componente aggiuntivo Marketplace AWS

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

  • Il prodotto in contenitore deve essere pubblicato in Marketplace AWS.

  • Il prodotto contenitore deve essere costruito in modo compatibile con entrambe AMD64 le ARM64 architetture.

  • Il prodotto contenitore non deve utilizzare il modello di prezzo Bring Your Own License (BYOL).

    Nota

    BYOLnon è supportato per la distribuzione di EKS componenti aggiuntivi di Amazon.

  • Devi rispettare tutti i requisiti dei prodotti basati su container, incluso l'invio di tutte le immagini dei container e Helm grafici nei ECR repository Amazon Marketplace AWS gestiti. Questo requisito include immagini open source, ad esempio. nginx Le immagini e i grafici non possono essere ospitati in altri repository esterni tra cui, a titolo esemplificativo, Amazon ECR Public Gallery, Docker Hube Quay.

  • Helm grafici - Prepara il software per essere distribuito tramite un Helm grafico. Il framework dei EKS componenti aggiuntivi di Amazon converte un Helm grafico in un manifesto. Medio Helm le funzionalità non sono supportate nei EKS sistemi Amazon. L'elenco seguente descrive i requisiti che devono essere soddisfatti prima dell'onboarding. In questo elenco, tutti Helm i comandi usano Helm versione 3.8.1:

    • Sono supportati tutti Capabilities gli oggetti, ad eccezione .APIVersions di. .APIVersionsnon è supportato per la non-built-in personalizzazione Kubernetes APIs.

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

    • Helm i ganci e la lookup funzione non sono supportati.

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

    • Il Helm il grafico deve passare con successo Helm Lint e Helm Modello senza errori. I comandi sono i seguenti:

      • Helm Flanugine — 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.

      • Helm Modello: 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 sostituite con il flag. —f

    • Archivia tutti i file binari dei container nei Marketplace AWS ECR repository Amazon. Per creare un manifesto, usa il Helm comando template mostrato in precedenza. Cerca nel manifesto eventuali riferimenti a immagini esterne come busybox o gcr immagini. Carica tutte le immagini dei container insieme alle dipendenze nei repository Marketplace AWS Amazon creati utilizzando l'opzione Add ECR 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 inserirlo in un wrapper con Helm grafico, vedi EKSComponenti aggiuntivi di Amazon: configurazione avanzata.

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

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

    Per gestire le installazioni segrete e di certificati, puoi fornire agli utenti finali le fasi successive all' pre-Add-oninstallazione o successive all'installazione. Il prodotto non deve fare affidamento su licenze esterne. Il prodotto deve funzionare in base alle Marketplace AWS autorizzazioni.

    Per ulteriori informazioni sulle limitazioni diaws_mp_configuration_schema.json, consulta. Requisiti di configurazione dei componenti aggiuntivi e procedure consigliate 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.

  • Crea l'opzione serviceAccount se applicabile: se il software è un software a pagamento o deve connettersi con altri, assicurati che Marketplace AWS Servizi AWSHelm il grafico viene creato serviceAccount per impostazione predefinita. Se la serviceAccount creazione è gestita da un parametro in un values.yaml file, imposta il valore del parametro sutrue. 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 demoni tracciabili: assicurati che il tuo diagramma Helm abbia un demonset o una distribuzione. Il framework EKS addon di Amazon monitora la distribuzione delle tue EKS risorse Amazon utilizzandole. Senza una distribuzione o un daemset tracciabili, il tuo addon potrebbe riscontrare un errore di distribuzione. Se il tuo addon non dispone di una distribuzione o di un daemset, ad esempio, se distribuisce una serie di risorse personalizzate o un job Kubernetes che non sono tracciabili, aggiungi un oggetto fittizio di distribuzione o daemonset.

  • Support AMD e ARM architetture: molti EKS clienti Amazon utilizzano ARM64 oggi le istanze AWS Graviton. Il software di terze parti deve supportare entrambe le architetture.

  • Integrazione con licenze o sistemi di misurazione Marketplace AWS: Marketplace AWS supporta più modelli APIs di fatturazione. Per ulteriori informazioni, consulta Integrazioni di fatturazione, misurazione e licenza dei prodotti container. Se desideri vendere il tuo prodotto tramite PAYG meccanismi, consulta. Configurazione della misurazione personalizzata per i prodotti container con AWS Marketplace Metering Service Se desideri vendere il tuo prodotto tramite un modello iniziale o contrattuale, consultaPrezzi 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 trasferite in ECR repository Marketplace AWS Amazon privati dello stesso elenco. Marketplace AWS

  • Fornisci istruzioni per l'implementazione 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.

  • IAMruoli: elenca tutte le AWS Identity and Access Management (IAM) politiche necessarie per il funzionamento o la connessione del software con altri. Servizi AWS

  • Aggiornamenti delle versioni: Amazon EKS rilascia nuove versioni di Kubernetes poche settimane dopo la versione upstream. Man mano che le nuove versioni dei EKS cluster Amazon diventano disponibili a livello generale, i fornitori hanno 45 giorni di tempo per certificare o aggiornare il proprio software in modo che sia compatibile con la nuova versione del EKS cluster Amazon. Se la tua attuale versione del componente aggiuntivo supporta 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 aggiuntiva 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 AmazonEKS: Gitops | monitoring | logging | cert-management | policy-management | cost-management | autoscaling | storage | kubernetes-management | service-mesh | etcd-backup | | load-balancer | local-registry| networking | Security | backup | ingress-controller | observability ingress-service-type

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

  • Il software deve essere venduto Marketplace AWS e integrato con Licenze e contabilizzazione dei prodotti a APIs pagamento. BYOLi prodotti non sono accettati.

Requisiti di configurazione dei componenti aggiuntivi e procedure consigliate per i fornitori di componenti aggiuntivi

Amazon EKS richiede la configurazione come stringa JSONdello schema Helm da fornitori di componenti aggiuntivi. I componenti aggiuntivi che richiedono le configurazioni richieste o che consentono configurazioni opzionali devono includere un aws_mp_configuration_schema.json file con la Helm Chart inviata a. Marketplace AWS Amazon EKS utilizzerà questo schema per convalidare l'input di configurazione dei clienti e rifiutare API le chiamate con valori di input non conformi allo schema. Le configurazioni aggiuntive rientrano in genere in due categorie:

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

  • Configurazioni specifiche del componente aggiuntivo come chiave di licenza, abilitazione delle funzionalità, ecc. URLs

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

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

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 EKS i componenti aggiuntivi di Amazon e impedirà il rilascio del componente aggiuntivo fino a quando 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 obbligatori 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 EKS console Amazon per ogni parametro di configurazione.

RBACdefinizione

I fornitori di componenti aggiuntivi devono definire e fornire le RBAC autorizzazioni necessarie per installare correttamente il componente aggiuntivo utilizzando il principio del privilegio minimo. Se è necessario modificare RBAC le autorizzazioni per le versioni più recenti del componente aggiuntivo o per eventuali correzioni relative a un problemaCVE, 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 di applicazione, API chiave, password, ecc. Attualmente, Amazon EKS APIs non supporta la trasmissione di informazioni segrete in testo semplice a causa delle implicazioni di sicurezza. Tuttavia, i clienti possono utilizzare la configurazione per passare il nome del Kubernetes Secret che contiene le chiavi necessarie al componente aggiuntivo. I clienti dovranno creare oggetti Kubernetes Secret contenenti le chiavi con lo stesso namespace come passaggio preliminare e quindi inserire il nome del Secret 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 confondano accidentalmente con la chiave effettiva. Ad esempio: appSecretName, ecc. connectionSecretName

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

Valori di configurazione di esempio

Puoi includere esempi di configurazione nel tuo 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

Di seguito sono riportati i parametri consigliati in un file di schema Helm rivolto ai clienti.

Parametro Descrizione Dovrebbe avere un valore predefinito?
additionalLabels Aggiungi etichette Kubernetes a tutti gli oggetti Kubernetes gestiti dal componente aggiuntivo. No
additionalAnnotations Aggiungi annotazioni Kubernetes a tutti gli oggetti Kubernetes gestiti dal componente aggiuntivo. No
podLabels Aggiungi le etichette Kubernetes ai pod gestiti dal componente aggiuntivo. No
podAnnotations 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 nodeSelector campo alle specifiche del tuo Pod e specificare le etichette dei nodi che desideri che abbia il nodo di destinazione. Potenzialmente, ad esempio solo nodi Linux
tolleranze Le tolleranze vengono applicate ai pod. Le tolleranze consentono allo scheduler di programmare i pod con macchie corrispondenti. Le tolleranze consentono la pianificazione ma non garantiscono la pianificazione. Forse è più comune con i daemonset
affinità La funzionalità di affinità è costituita da due tipi di affinità: l'affinità tra nodi funziona come il nodeSelector campo, ma è più espressiva e consente di specificare regole flessibili, mentre l'affinità/antiaffinità tra POD consente di vincolare i Pod alle etichette di altri Pod. Probabile
topologySpreadConstraints È 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. Ciò può contribuire a ottenere un'elevata disponibilità e un utilizzo efficiente delle risorse. Probabile
richiesta/limiti di risorse Specificare la quantità di cpu/memoria necessaria a ciascun contenitore. Si consiglia vivamente di impostare le richieste. I limiti sono facoltativi. Sì
repliche 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, se necessario. Ad esempio, il EBS CSI driver Amazon contiene due componenti principali, controller e node agent: i clienti richiedono selettori/tolleranze di nodo diversi per ogni componente.

Nota

I valori predefiniti definiti nello JSON schema servono esclusivamente a scopi di documentazione per l'utente e non sostituiscono la necessità di avere i valori predefiniti legittimi nel file. values.yaml Se utilizzi la proprietà predefinita, assicurati che quella predefinita values.yaml corrisponda a quella nello schema e nei due artefatti (values.schema.jsonevalues.yaml) rimanga sincronizzata ogni volta che vengono apportate modifiche al 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

I parametri dei metadati del cluster come clusterNameregion,vpcId,accountId, e altri possono essere richiesti da vari componenti aggiuntivi (ad esempio, Elastic Load Balancing Controller). Qualsiasi parametro simile a questi conosciuto dal EKS servizio Amazon verrà inserito automaticamente dai EKS componenti aggiuntivi di Amazon e non sarà l'utente a doverlo specificare come opzione di configurazione. Questi parametri includono:

  • AWS regione

  • Nome EKS del cluster Amazon

  • VPCID del cluster

  • Registro dei container, in particolare per gli account build-prod, utilizzato dai componenti aggiuntivi di rete

  • DNScluster IP, in particolare per il componente aggiuntivo cordens

  • APIEndpoint EKS del cluster Amazon

  • IPv4abilitato sul cluster

  • IPv6abilitato sul cluster

  • Delega con prefisso IPv6 enabled on cluster

I fornitori di componenti aggiuntivi devono assicurarsi che il modello sia definito per tali parametri applicabili. Ciascuno dei parametri precedenti avrà un parameterType attributo predefinito definito da AmazonEKS. I metadati di rilascio specificheranno la mappatura tra e. parameterType 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 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 sono configurabili in un file di schema Helm destinato ai clienti. I parametri devono avere impostazioni predefinite non modificabili o non essere inclusi affatto nel modello aggiuntivo.

Parametro Descrizione Dovrebbe avere un valore predefinito?
image Immagine del contenitore che verrà distribuita nel cluster Kubernetes. No, gestito tramite una definizione aggiuntiva
imagePullSecrets Configurazione di un pod per utilizzare un segreto da estrarre da un registro privato. N/D
livenessProbe Il processo Kubelet utilizza sonde liveness per sapere quando riavviare un contenitore. Ad esempio, le sonde liveness potrebbero catturare un deadlock, in cui un'applicazione è in esecuzione ma non è in grado di fare progressi. Il riavvio di un contenitore in tale stato può contribuire a rendere l'applicazione più disponibile nonostante i bug. Sì
readinessProbe È 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 uso 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ì
startupProbe Il kubelet utilizza le sonde di avvio per sapere quando è stata avviata un'applicazione contenitore. Se una sonda di questo tipo è configurata, disabilita i controlli di vivacità e prontezza 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 uccisi dal kubelet prima che siano operativi. Facoltativo
podDisruptionBudget Definite un Pod Discruption Budget (PDB) per garantire un numero minimo di operazioni continue durante le interruzioni volontariePODS. A PDB limita il numero di Pod di un'applicazione replicata che non funzionano contemporaneamente a causa di interruzioni volontarie. Ad esempio, un'applicazione basata sul quorum vorrebbe garantire che il numero di repliche in esecuzione non scenda mai al di sotto del numero necessario per il 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 l'impostazione predefinita è più di due repliche
serviceAccount (nome) Nome dell'account di servizio con cui verranno eseguiti i pod. Sì
serviceAccount (annotazioni) Annotazioni applicate all'account del servizio. In genere utilizzato per la IAM funzionalità Roles for Service Accounts No, il ruolo dell'account di IAM servizio ARN è impostato nei EKS componenti aggiuntivi API Amazon di primo livello. Un'eccezione a questa regola è se il tuo componente aggiuntivo ha più distribuzioni/controller (come Flux) e richiede un ruolo separato. IRSA ARNs
priorityClassName La priorità indica l'importanza di un Pod rispetto agli altri Pod. Se un Pod non può essere programmato, lo scheduler cerca di anticipare (espellere) i Pod con priorità inferiore per rendere possibile la pianificazione dei 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.
podSecurityContext Un contesto di sicurezza definisce i privilegi e le impostazioni di controllo degli accessi per un Pod o un Container. In genere utilizzato per impostare fsGroup , che era richiesto per i cluster IRSA v1.19 e precedenti. Improbabile, dato che Amazon EKS non supporta più Kubernetes v1.19
securityContext Un contesto di sicurezza definisce i privilegi e le impostazioni di controllo degli accessi per un Pod o un contenitore. Sì
updateStrategy Speciifica la strategia utilizzata per sostituire i vecchi Pod con altri nuovi. Sì
nameOverride Sostituisci il nome dei pod. No
podSecurityPolicy

Applica le restrizioni sui parametri.

 No, PSPs sono obsoleti
extraVolumeMounts/extraVolumes

IRSAUtilizzato per EKS cluster non Amazon.

No