Exigences relatives aux produits basées sur les contenants - AWS Marketplace
Exigences de sécuritéExigences relatives à l'accèsExigences en matière d'information du clientExigences relatives à l'utilisation du produitExigences relatives à l'architectureInstructions d'utilisation du produit contenantExigences relatives aux produits complémentaires Amazon EKS

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Exigences relatives aux produits basées sur les contenants

AWS Marketplace maintient les exigences suivantes pour tous les produits et offres basés sur des conteneurs sur. AWS Marketplace Ces exigences contribuent à promouvoir un catalogue sûr, sécurisé et fiable pour nos clients. Nous encourageons également les vendeurs à examiner la mise en œuvre de contrôles et de protocoles supplémentaires, le cas échéant, pour répondre aux besoins spécifiques de leurs produits.

Tous les produits et leurs métadonnées associées sont examinés lors de leur soumission afin de s'assurer qu'ils respectent ou dépassent AWS Marketplace les exigences actuelles. Nous révisons et ajustons ces politiques pour répondre à l'évolution de nos exigences en matière de sécurité et d'utilisation. AWS Marketplace vérifie en permanence que les produits existants continuent de répondre aux modifications apportées à ces exigences. Si les produits ne sont pas conformes, nous vous AWS Marketplace contacterons pour mettre à jour votre produit. Dans certains cas, votre produit peut être temporairement indisponible pour les nouveaux abonnés tant que les problèmes ne sont pas résolus.

Exigences de sécurité

Tous les produits en conteneur doivent respecter les exigences de sécurité suivantes :

  • Les images des conteneurs Docker doivent être exemptes de tout logiciel malveillant, virus ou vulnérabilité connu. Lorsque vous ajoutez une nouvelle version à votre produit conteneur, les images du conteneur incluses dans la version sont numérisées.

  • Si vos produits basés sur des conteneurs nécessitent un accès pour gérer les AWS ressources, l'accès doit être obtenu via des rôles IAM pour les comptes de service (s'ils sont exécutés via Amazon Elastic Kubernetes Service (Amazon EKS)) ou des rôles IAM pour les tâches (s'ils sont exécutés via Amazon Elastic Container Service (Amazon ECS)) au lieu de demander une clé d'accès aux utilisateurs.

  • Les produits basés sur des conteneurs ne doivent nécessiter que le minimum de privilèges pour fonctionner. Pour plus d'informations, consultez les sections Sécurité ECS et Sécurité EKS.

  • Les images de conteneur doivent être configurées pour s'exécuter avec des privilèges non root par défaut.

Exigences relatives à l'accès

Tous les produits en contenant doivent respecter les exigences d'accès suivantes :

  • Les produits basés sur des conteneurs doivent utiliser un mot de passe aléatoire initial. Les produits basés sur des conteneurs ne doivent pas utiliser de mots de passe initiaux fixes ou vides pour l'accès administratif externe (par exemple, pour se connecter à l'application via une interface Web). L'acheteur doit être invité à saisir ce mot de passe aléatoire avant d'être autorisé à définir ou à modifier ses propres informations d'identification.

  • Tout accès extérieur à l'application doit être explicitement accepté et autorisé par les clients.

Exigences en matière d'information du client

Tous les produits en conteneur doivent respecter les exigences d'information client suivantes :

  • Le logiciel ne doit pas collecter ou exporter les données du client à l'insu du client et sans son consentement exprès, sauf si cela est exigé par BYOL (Bring Your Own License). Les applications qui collectent ou exportent des données clients doivent suivre les directives suivantes :

    • La collecte des données clients doit être en libre-service, automatisée et sécurisée. Les acheteurs ne doivent pas attendre l'approbation des vendeurs pour déployer le logiciel.

    • Les exigences relatives aux données clients doivent être clairement indiquées dans la description ou les instructions d'utilisation de l'annonce. Cela inclut ce qui est collecté, l'emplacement où les données du client seront stockées et la manière dont elles seront utilisées. Par exemple, ce produit collecte votre nom et votre adresse e-mail. Ces informations sont envoyées et stockées par le<company name>. Ces informations ne seront utilisées que pour contacter l'acheteur en ce qui concerne le. <product name>

    • Les informations de paiement ne doivent pas être collectées.

Exigences relatives à l'utilisation du produit

Tous les produits en contenant doivent respecter les exigences d'utilisation suivantes :

  • Les vendeurs ne peuvent mettre en vente que des produits entièrement fonctionnels. Les produits bêta ou en version préliminaire à des fins d'essai ou d'évaluation ne sont pas autorisés. Les éditions pour développeurs, communautaires et BYOL des logiciels commerciaux sont prises en charge si le vendeur fournit une version payante équivalente AWS Marketplace dans les 90 jours suivant la fourniture de l'édition gratuite.

  • Toutes les instructions d'utilisation d'un produit basé sur un conteneur doivent inclure toutes les étapes de déploiement des produits basés sur un conteneur. Les instructions d'utilisation doivent fournir des commandes et des ressources de déploiement pointant vers les images de conteneur correspondantes sur AWS Marketplace.

  • Les produits basés sur des conteneurs doivent inclure toutes les images de conteneurs dont un abonné a besoin pour utiliser le logiciel. En outre, les produits basés sur des conteneurs ne doivent pas obliger l'utilisateur à lancer le produit à l'aide d'images provenant de l'extérieur AWS Marketplace (par exemple, des images de conteneurs provenant de référentiels tiers).

  • Les conteneurs et leurs logiciels doivent être déployables en libre-service et ne doivent pas nécessiter de méthodes de paiement ou de coûts supplémentaires. Les applications qui nécessitent des dépendances externes lors du déploiement doivent suivre les directives suivantes :

    • L'exigence doit être indiquée dans la description ou les instructions d'utilisation de l'annonce. Par exemple, ce produit nécessite une connexion Internet pour être déployé correctement. Les packages suivants sont téléchargés lors du déploiement : <list of package>

    • Les vendeurs sont responsables de l'utilisation de toutes les dépendances externes et de la garantie de leur disponibilité et de leur sécurité.

    • Si les dépendances externes ne sont plus disponibles, le produit doit AWS Marketplace également être retiré.

    • Les dépendances externes ne doivent pas nécessiter de méthodes de paiement ou de coûts supplémentaires.

  • Les conteneurs qui nécessitent une connexion permanente à des ressources externes ne relevant pas du contrôle direct de l'acheteur (par exemple, des API externes ou Services AWS gérées par le vendeur ou un tiers) doivent respecter les directives suivantes :

    • L'exigence doit être indiquée dans la description ou les instructions d'utilisation de l'annonce. Par exemple, ce produit nécessite une connexion Internet permanente. Les services externes permanents suivants sont nécessaires pour fonctionner correctement :. <list of resources>

    • Les vendeurs sont responsables de l'utilisation de toutes les ressources externes, de leur disponibilité et de leur sécurité.

    • Si les ressources externes ne sont plus disponibles, le produit doit AWS Marketplace également être retiré.

    • Les ressources externes ne doivent pas nécessiter de méthodes de paiement ou de coûts supplémentaires et la configuration de la connexion doit être automatisée.

  • Le logiciel et les métadonnées du produit ne doivent pas contenir de langage qui redirige les utilisateurs vers d'autres plateformes cloud, des produits supplémentaires ou des services de vente incitative qui ne sont pas disponibles sur. AWS Marketplace

  • Si votre produit est un module complémentaire à un autre produit ou au produit d'un autre éditeur de logiciels indépendants, la description de votre produit doit indiquer qu'il étend les fonctionnalités de l'autre produit et que, sans lui, l'utilité de votre produit est très limitée. Par exemple, ce produit étend les fonctionnalités et sans lui, son utilité est très limitée. <product name> Veuillez noter que cette liste peut nécessiter sa propre licence pour accéder à toutes les fonctionnalités. <product name>

Exigences relatives à l'architecture

Tous les produits basés sur des conteneurs doivent respecter les exigences d'architecture suivantes :

  • Les images du conteneur source pour AWS Marketplace doivent être transférées vers le référentiel Amazon Elastic Container Registry (Amazon ECR) détenu par. AWS Marketplace Vous pouvez créer ces référentiels dans les produits Portail de gestion AWS Marketplace sous-serveur pour chacune de vos listes de produits en conteneur.

  • Les images de conteneur doivent être basées sur Linux.

  • Les produits payants basés sur des conteneurs doivent pouvoir être déployés sur Amazon ECS, Amazon EKS ou. AWS Fargate

  • Les produits payants basés sur des conteneurs avec une tarification contractuelle et une intégration AWS License Manager doivent être déployés sur Amazon EKS, Amazon ECS Anywhere AWS Fargate, Amazon ECS Anywhere, Red Hat OpenShift Service on AWS (ROSA), sur des clusters Kubernetes autogérés sur site ou sur Amazon Elastic Compute Cloud.

Instructions d'utilisation du produit contenant

Lorsque vous créez des instructions d'utilisation pour votre produit en conteneur, suivez les étapes et les instructions indiquées dansInstructions d'utilisation de l'AMI et du produit en conteneur.

Exigences relatives aux produits complémentaires Amazon EKS

Un module complémentaire Amazon EKS est un logiciel qui fournit des fonctionnalités opérationnelles aux Kubernetes applications mais qui n'est pas spécifique à l'application. Par exemple, un module complémentaire Amazon EKS inclut des agents ou des Kubernetes pilotes d'observabilité qui permettent au cluster d'interagir avec les AWS ressources sous-jacentes pour la mise en réseau, le calcul et le stockage.

En tant que vendeur de produits conteneurisés, vous pouvez choisir parmi plusieurs options de déploiement, notamment Amazon EKS. Vous pouvez publier une version de votre produit en tant que AWS Marketplace module complémentaire dans le catalogue des modules complémentaires Amazon EKS. Votre module complémentaire apparaît dans la console Amazon EKS à côté des modules complémentaires gérés par d'autres fournisseurs ou gérés par AWS d'autres fournisseurs. Vos acheteurs peuvent déployer votre logiciel en tant que module complémentaire aussi facilement qu'ils le font pour les autres modules complémentaires.

Pour plus d'informations, veuillez consulter Modules complémentaires Amazon EKS dans le Guide de l'utilisateur Amazon EKS.

Préparation de votre produit en pot en tant que AWS Marketplace complément

Pour publier votre produit en conteneur en tant que AWS Marketplace module complémentaire, celui-ci doit répondre aux exigences suivantes :

  • Votre produit en conteneur doit être publié dans AWS Marketplace.

  • Votre produit conteneur doit être compatible avec les architectures AMD64 et ARM64.

  • Votre produit en conteneur ne doit pas utiliser le modèle de tarification BYOL (Bring Your Own License).

    Note

    Le BYOL n'est pas pris en charge pour la livraison des modules complémentaires Amazon EKS.

  • Vous devez respecter toutes les exigences relatives aux produits liés aux conteneurs, y compris le transfert de toutes les images et de tous les Helm graphiques des conteneurs dans les référentiels AWS Marketplace Amazon ECR gérés. Cette exigence inclut les images open source, par exemple,nginx. Les images et les graphiques ne peuvent pas être hébergés dans d'autres référentiels externes, y compris, mais sans s'y limiter, Amazon ECR Public GalleryDocker Hub, et. Quay

  • Helmgraphiques - Préparez votre logiciel à déployer à l'aide d'un Helm graphique. Le framework complémentaire Amazon EKS convertit un Helm graphique en manifeste. Certaines Helm fonctionnalités ne sont pas prises en charge dans les systèmes Amazon EKS. La liste suivante décrit les exigences qui doivent être satisfaites avant l'intégration. Dans cette liste, toutes les Helm commandes utilisent Helm la version 3.8.1 :

    • Tous les Capabilities objets sont pris en charge, à l'exception de.APIVersions. .APIVersionsn'est pas pris en charge pour les Kubernetes API non-built-in personnalisées.

    • Seuls les Release.Namespace objets Release.Name et sont pris en charge.

    • Helmles crochets et la lookup fonction ne sont pas pris en charge.

    • Tous les graphiques dépendants doivent être situés dans le Helm graphique principal (spécifié avec le chemin du référentiel file ://...).

    • Le Helm graphique doit réussir à passer Helm Lint et Helm Template sans erreur. Les commandes sont les suivantes :

      • HelmPeluche — helm lint helm-chart

        Les problèmes courants incluent les graphiques non déclarés dans les métadonnées du graphique parent. Par exemple, chart metadata is missing these dependencies: chart-base Error: 1 chart(s) linted, 1 chart(s) failed

      • HelmModèle — 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

        Transmettez toutes les configurations remplacées avec le —f drapeau.

    • Stockez tous les fichiers binaires des conteneurs dans les AWS Marketplace dépôts Amazon ECR. Pour créer un manifeste, utilisez la commande Helm template présentée précédemment. Recherchez dans le manifeste toute référence à une image externe, telle que busybox des gcr images. Téléchargez toutes les images de conteneur ainsi que les dépendances dans les dépôts AWS Marketplace Amazon ECR créés à l'aide de l'option Ajouter un référentiel dans le menu déroulant des demandes.

  • Configuration personnalisée : vous pouvez ajouter des variables personnalisées lors du déploiement. Pour plus d'informations sur la façon d'identifier l'expérience de l'utilisateur final, de nommer le logiciel aws_mp_configuration_schema.json et de le mettre dans un emballage contenant le Helm graphique, consultez la section Extensions Amazon EKS : Configuration avancée.

    Selon le mot clé « $schema », $schema il doit s'agir d'un URI pointant vers une application/schema+json ressource valide.

    Ce fichier ne doit pas accepter d'informations sensibles telles que les mots de passe, les clés de licence et les certificats.

    Pour gérer les secrets et les installations de certificats, vous pouvez fournir aux utilisateurs finaux les étapes à suivre avant ou après l'installation du module complémentaire. Le produit ne doit pas reposer sur des licences externes. Le produit doit fonctionner en fonction des AWS Marketplace droits.

    Pour plus d'informations sur les limitations relatives àaws_mp_configuration_schema.json, voirExigences de configuration des modules complémentaires et meilleures pratiques pour les fournisseurs de modules complémentaires.

  • Identifiez et créez l'espace de noms dans lequel le logiciel sera déployé : dans la première version de votre produit, vous devez identifier l'espace de noms dans lequel le logiciel sera déployé en ajoutant un espace de noms modèle.

  • Créez le cas serviceAccount échéant — S'il s'agit d'un logiciel payant AWS Marketplace ou s'il doit être connecté à un autre Services AWS, assurez-vous que le Helm graphique est créé serviceAccount par défaut. Si la serviceAccount création est gérée par un paramètre dans un values.yaml fichier, définissez la valeur du paramètre surtrue. Par exemple, serviceAccount.create = true. Cela est nécessaire car le client peut choisir d'installer le module complémentaire en héritant des autorisations de l'instance de nœud sous-jacente qui possède déjà les autorisations requises. Si le graphique Helm ne crée pas leserviceAccount, les autorisations ne peuvent pas être liées auserviceAccount.

  • Déploiements ou daemonsets traçables : assurez-vous que votre diagramme Helm comporte un daemonset ou un déploiement. Le framework d'extensions Amazon EKS suit le déploiement de vos ressources Amazon EKS à l'aide de celles-ci. En l'absence d'un déploiement ou d'un daemonset traçable, votre addon sera confronté à une erreur de déploiement. Si votre addon ne dispose pas d'un déploiement ou d'un daemonset, par exemple, s'il déploie un ensemble de ressources personnalisées ou une tâche Kubernetes qui ne sont pas traçables, ajoutez un déploiement factice ou un objet daemonset.

  • Support pour les architectures AMD et ARM — De nombreux clients Amazon EKS utilisent aujourd'hui ARM64 pour utiliser les instances AWS Graviton. Les logiciels tiers doivent prendre en charge les deux architectures.

  • Intégrez les API de licence ou de mesure depuis AWS Marketplace : AWS Marketplace prend en charge plusieurs modèles de facturation. Pour plus d’informations, consultez Intégrations relatives à la facturation, au mesurage et aux licences des produits conteneurisés. Si vous souhaitez vendre votre produit par le biais de mécanismes PAYG, consultezMesure personnalisée pour les produits conteneurisés avec AWS Marketplace Metering Service. Si vous souhaitez vendre votre produit par le biais d'un modèle initial ou contractuel, consultezTarification contractuelle pour les produits en conteneur avec AWS License Manager.

  • Téléchargez le logiciel et tous les artefacts et dépendances : le graphique Helm doit être autonome et ne doit pas nécessiter de dépendances provenant de sources externes, GitHub par exemple. Si le logiciel nécessite des dépendances externes, celles-ci doivent être transférées vers des référentiels Amazon ECR AWS Marketplace privés sous la même AWS Marketplace liste.

  • Fournissez des instructions de déploiement sur votre site Web : nous vous demandons d'héberger un guide de déploiement destiné aux clients afin d'identifier comment déployer votre logiciel à l'aide de la commande create-addon.

  • Rôles IAM — Répertoriez toutes les politiques AWS Identity and Access Management (IAM) requises pour que votre logiciel fonctionne ou se connecte à d'autres. Services AWS

  • Mises à jour des versions : Amazon EKS publie de nouvelles versions de Kubernetes quelques semaines après la publication en amont. À mesure que les nouvelles versions du cluster Amazon EKS sont généralement disponibles, les fournisseurs ont 45 jours pour certifier ou mettre à jour leur logiciel afin qu'il soit compatible avec la nouvelle version du cluster Amazon EKS. Si vos versions actuelles du module complémentaire sont compatibles avec la nouvelle version de Kubernetes, validez-la et certifiez-la afin que nous puissions mettre à jour la matrice de compatibilité des versions. Si une nouvelle version complémentaire est nécessaire pour prendre en charge la nouvelle version de Kubernetes, veuillez soumettre la nouvelle version pour intégration.

  • Le logiciel du partenaire doit appartenir à l'un des types suivants ou être un logiciel opérationnel destiné à améliorer Kubernetes ou Amazon EKS : Gitops | surveillance | journalisation | gestion des certificats | gestion des politiques | gestion des coûts | mise à l'échelle automatique | stockage | kubernetes-management | service-mesh | etcd-backup | | équilibreur de charge | registre local | mise en réseau | sécurité | sauvegarde | contrôleur d'entrée | observabilité ingress-service-type

  • Le logiciel ne peut pas être une interface réseau de conteneurs (CNI).

  • Les logiciels doivent être vendus AWS Marketplace et intégrés aux API de gestion des licences et de mesure pour les produits payants. Les produits BYOL ne sont pas acceptés.

Exigences de configuration des modules complémentaires et meilleures pratiques pour les fournisseurs de modules complémentaires

Amazon EKS nécessite une configuration sous forme de chaîne de schéma Helm JSON auprès des fournisseurs de modules complémentaires. Les modules complémentaires qui nécessitent des configurations requises ou autorisent des configurations facultatives doivent inclure un aws_mp_configuration_schema.json fichier contenant le Helm Chart soumis à AWS Marketplace. Amazon EKS utilisera ce schéma pour valider les entrées de configuration fournies par les clients et rejeter les appels d'API dont les valeurs d'entrée ne sont pas conformes au schéma. Les configurations complémentaires se répartissent généralement en deux catégories :

  • Configuration des propriétés générales de Kubernetes telles que les étiquettes, les tolérations, NodeSelector, etc.

  • Configurations spécifiques aux modules complémentaires, telles que la clé de licence, l'activation des fonctionnalités, les URL, etc.

Cette section se concentre sur la première catégorie liée aux propriétés générales de Kubernetes.

Amazon EKS recommande de suivre les meilleures pratiques en matière de configuration des modules complémentaires Amazon EKS.

Exigences relatives au schéma

Lorsque vous définissez le schéma JSON, assurez-vous d'utiliser une version de jsonschema prise en charge par les modules complémentaires Amazon EKS.

Liste des schémas pris en charge :

  • 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'utilisation d'une autre version du schéma JSON est incompatible avec les modules complémentaires Amazon EKS et empêchera leur publication tant que le problème ne sera pas résolu.

Exemple de fichier de schéma 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

Les paramètres de configuration doivent être CamelCase et seront rejetés s'ils ne respectent pas ce format.

Les descriptions sont obligatoires

Incluez toujours des descriptions pertinentes pour les propriétés du schéma. Cette description sera utilisée pour afficher les noms d'étiquette dans la console Amazon EKS pour chaque paramètre de configuration.

Définition du RBAC

Les fournisseurs de modules complémentaires doivent définir et fournir les autorisations RBAC nécessaires pour installer correctement le module complémentaire en utilisant le principe du moindre privilège. Si les autorisations RBAC doivent être modifiées pour les nouvelles versions d'un module complémentaire ou pour tout correctif visant à résoudre un CVE, les fournisseurs de modules complémentaires devront informer l'équipe Amazon EKS de cette modification. Les autorisations requises pour chaque ressource Kubernetes doivent être limitées au nom de ressource de l'objet. 

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

Cette section s'applique uniquement aux modules complémentaires qui nécessitent que les clients configurent des informations secrètes telles que la clé d'application, la clé d'API, le mot de passe, etc. À l'heure actuelle, les API Amazon EKS ne prennent pas en charge la transmission d'informations secrètes en texte brut pour des raisons de sécurité. Cependant, les clients peuvent utiliser la configuration pour transmettre le nom du Kubernetes Secret qui contient les clés nécessaires au module complémentaire. Les clients devront créer des objets Kubernetes Secret contenant les clés avec le même espace de noms comme étape préalable, puis transmettre le nom du secret à l'aide du blob de configuration lors de la création du module complémentaire. Nous recommandons aux fournisseurs de modules complémentaires de nommer les propriétés du schéma afin que les clients ne le confondent pas accidentellement avec la clé réelle. Par exemple : appSecretName, connectionSecretName etc.

En résumé, les fournisseurs de modules complémentaires peuvent tirer parti du schéma pour permettre aux clients de transmettre le nom du secret, mais pas les clés qui détiendront réellement le secret lui-même.

Exemples de valeurs de configuration

Vous pouvez inclure des exemples de configuration dans votre schéma pour aider les clients à configurer les modules complémentaires. L'exemple suivant est tiré du schéma de AWS Distro pour OpenTelemetry module complémentaire.

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

Paramètres courants autorisés pour la configuration

Les paramètres suivants sont recommandés dans un fichier de schéma Helm destiné au client.

Paramètre Description Devrait avoir une valeur par défaut ?
Étiquettes supplémentaires Ajoutez des étiquettes Kubernetes à tous les objets Kubernetes gérés par le module complémentaire. Non
Annotations supplémentaires Ajoutez des annotations Kubernetes à tous les objets Kubernetes gérés par le module complémentaire. Non
Étiquettes POD Ajoutez des étiquettes Kubernetes aux pods gérés par le module complémentaire. Non
Annotations de Podan Ajoutez des annotations Kubernetes aux pods gérés par le module complémentaire. Non
logLevel Niveau de journalisation pour les composants gérés par le module complémentaire. Oui
Sélecteur de nœuds Forme recommandée la plus simple de contrainte de sélection de nœuds. Vous pouvez ajouter le champ NodeSelector à la spécification de votre pod et spécifier les étiquettes de nœud que vous souhaitez attribuer au nœud cible. Potentiellement, par exemple, les nœuds Linux uniquement
tolérances Des tolérances sont appliquées aux gousses. Les tolérances permettent au planificateur de planifier des pods avec les teintes correspondantes. Les tolérances autorisent la planification mais ne garantissent pas la planification. Peut-être, plus courant avec les daemonsets
affinité La fonction d'affinité comprend deux types d'affinité : l'affinité des nœuds fonctionne comme le champ NodeSelector, mais elle est plus expressive et vous permet de spécifier des règles souples, tandis que l'affinité/anti-affinité entre les pods vous permet de restreindre les pods par rapport aux étiquettes des autres pods. Peut-être
topologie SpreadConstraints Vous pouvez utiliser les contraintes de propagation topologique pour contrôler la manière dont les pods sont répartis dans votre cluster entre les domaines de défaillance tels que les régions, les zones, les nœuds et les autres domaines topologiques définis par l'utilisateur. Cela peut aider à atteindre une haute disponibilité ainsi qu'une utilisation efficace des ressources. Peut-être
demande/limites de ressources Spécifiez la quantité de cpu/mémoire dont chaque conteneur a besoin. Il est fortement recommandé de définir des demandes. Les limites sont facultatives. Oui
répliques Nombre de répliques des pods gérés par le module complémentaire. Non applicable aux daemonsets. Oui
Note

Pour les paramètres de configuration de la planification de la charge de travail, vous devrez peut-être séparer les composants de niveau supérieur dans le schéma si nécessaire. Par exemple, le pilote Amazon EBS CSI contient deux composants principaux, le contrôleur et l'agent de nœud. Les clients ont besoin de sélecteurs de nœuds et de tolérances différents pour chaque composant.

Note

Les valeurs par défaut définies dans le schéma JSON sont uniquement destinées à la documentation utilisateur et ne remplacent pas la nécessité d'avoir la valeur par défaut légitime dans le values.yaml fichier. Si vous utilisez la propriété par défaut, assurez-vous que la valeur par défaut values.yaml correspond à celle du schéma et que les deux artefacts (values.schema.jsonetvalues.yaml) restent synchronisés chaque fois que des modifications sont apportées au graphique de Helm.

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

Paramètres courants non autorisés pour la configuration

Les paramètres de métadonnées du cluster tels que clusterNameregion,vpcId,accountId,, et d'autres peuvent être requis par divers modules complémentaires (par exemple, Elastic Load Balancing Controller). Tout paramètre similaire connu par le service Amazon EKS sera automatiquement injecté par les modules complémentaires Amazon EKS, et il n'incombe pas à l'utilisateur de le spécifier comme option de configuration. Ces paramètres incluent :

  • AWS région

  • Nom du cluster Amazon EKS

  • ID VPC du cluster

  • Registre de conteneurs, spécifiquement pour les comptes build-prod, utilisé par les modules complémentaires réseau

  • IP du cluster DNS, spécifiquement pour le module complémentaire Coredns

  • Point de terminaison de l'API du cluster Amazon EKS

  • IPv4 activé sur le cluster

  • IPv6 activé sur le cluster

  • Délégation de préfixe pour IPv6 activée sur le cluster

Les fournisseurs de modules complémentaires doivent s'assurer que vous avez défini un modèle pour ces paramètres applicables. Chacun des paramètres ci-dessus aura un parameterType attribut prédéfini défini par Amazon EKS. Les métadonnées de version spécifieront le mappage entre le parameterType et le nom/chemin du paramètre dans le modèle. Ainsi, les valeurs peuvent être transmises dynamiquement par Amazon EKS sans que les clients aient à les spécifier par le biais de configurations, ce qui donne également la flexibilité aux fournisseurs de modules complémentaires de définir leur propre nom/chemin de modèle. Les paramètres tels que ceux ci-dessus dont Amazon EKS a besoin pour injecter dynamiquement doivent être exclus du fichier de schéma.

Exemple de mappage à partir des métadonnées de publication

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

Il n'est pas recommandé de configurer les paramètres suivants dans un fichier de schéma Helm destiné au client. Soit les paramètres doivent avoir des valeurs par défaut non modifiables, soit ne pas être inclus du tout dans le modèle de module complémentaire.

Paramètre Description Devrait avoir une valeur par défaut ?
image Image de conteneur qui sera déployée sur le cluster Kubernetes. Non, géré via la définition d'un module complémentaire
image PullSecrets Configuration d'un pod pour utiliser un secret à extraire d'un registre privé. N/A
Sonde Liveness Le processus Kubelet utilise des sondes de réactivité pour savoir quand redémarrer un conteneur. Par exemple, les sondes Liveness peuvent détecter un blocage, lorsqu'une application est en cours d'exécution, mais ne parvient pas à progresser. Le redémarrage d'un conteneur dans un tel état peut contribuer à rendre l'application plus disponible malgré les bogues. Oui
Sonde de préparation Il est important que vous disposiez d'une sonde de disponibilité pour vos contenants. De cette façon, le processus Kubelet exécuté sur votre plan de données saura quand le conteneur est prêt à desservir le trafic. Un pod est considéré comme prêt lorsque tous ses conteneurs sont prêts. L'une des utilisations de ce signal consiste à contrôler quels pods sont utilisés comme backends pour les services. Lorsqu'un pod n'est pas prêt, il est retiré des équilibreurs de charge de service. Oui
Sonde de démarrage Le kubelet utilise des sondes de démarrage pour savoir quand une application conteneur a démarré. Si une telle sonde est configurée, elle désactive les contrôles de réactivité et de disponibilité jusqu'à ce qu'elle aboutisse, afin de s'assurer que ces sondes n'interfèrent pas avec le démarrage de l'application. Cela peut être utilisé pour adopter des contrôles de vitalité sur les conteneurs à démarrage lent, afin d'éviter qu'ils ne soient tués par le kubelet avant qu'ils ne soient opérationnels. Facultatif
gousse DisruptionBudget Définissez un budget de perturbation des pods (PDB) pour garantir qu'un nombre minimum de PODS continuent de fonctionner pendant les interruptions volontaires. Un PDB limite le nombre de pods d'une application répliquée qui sont simultanément indisponibles en raison d'interruptions volontaires. Par exemple, une application basée sur un quorum souhaite s'assurer que le nombre de répliques en cours d'exécution ne soit jamais inférieur au nombre requis pour un quorum. Une interface Web peut vouloir s'assurer que le nombre de répliques servant la charge ne tombe jamais en dessous d'un certain pourcentage du total. Oui, si vous utilisez par défaut plus de deux répliques
ServiceAccount (nom) Nom du compte de service sous lequel les pods seront exécutés. Oui
Compte de service (annotations) Annotations appliquées au compte de service. Généralement utilisé pour la fonctionnalité Rôles IAM pour les comptes de service Non, l'ARN du rôle du compte de service IAM est défini dans l'API des modules complémentaires Amazon EKS de haut niveau. Il existe une exception à cette règle si votre module complémentaire comporte plusieurs déploiements/contrôleurs (tels que Flux) et nécessite des ARN de rôle IRSA distincts.
priorité ClassName La priorité indique l'importance d'un pod par rapport aux autres pods. Si un pod ne peut pas être programmé, le planificateur essaie de préempter (expulser) les pods moins prioritaires afin de permettre la planification du pod en attente. Oui. La plupart des modules complémentaires sont essentiels au fonctionnement du cluster et doivent avoir une classe de priorité définie par défaut.
gousse SecurityContext Un contexte de sécurité définit les paramètres de privilège et de contrôle d'accès pour un pod ou un conteneur. Généralement utilisé pour définir FSGroup, qui était requis pour IRSA dans les clusters v1.19 et inférieurs. Peu probable, étant donné qu'Amazon EKS ne prend plus en charge Kubernetes v1.19
Contexte de sécurité Un contexte de sécurité définit les paramètres de privilège et de contrôle d'accès pour un pod ou un conteneur. Oui
Stratégie de mise à jour Spécifie la stratégie utilisée pour remplacer les anciens pods par de nouveaux. Oui
Nom Override Remplacez le nom des pods. Non
gousse SecurityPolicy

Appliquez des restrictions sur les paramètres.

 Non, les PSP sont obsolètes
VolumeMountssur/ExtraVolumes

Utilisé pour IRSA dans des clusters autres qu'Amazon EKS.

Non