Exigences relatives aux produits basées sur les conteneurs pour AWS Marketplace - 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 EKS complémentaires Amazon

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 conteneurs pour AWS Marketplace

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 par le biais de IAMrôles pour les comptes de service (s'ils sont exécutés via Amazon Elastic Kubernetes Service EKS (Amazon IAM)) ou de rôles pour les tâches (s'ils sont exécutés via Amazon Elastic Container Service ECS (Amazon)) 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 ECSla section Sécurité et EKSsécurité.

  • 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 requis 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 de logiciels destinées aux développeurs, à la communauté et aux BYOL éditions commerciales 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, externes APIs 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 ajout à un autre produit ou au produit ISV d'un autre, votre description doit indiquer qu'il étend les fonctionnalités de l'autre produit et que, sans lui, votre produit n'a qu'une utilité 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 (AmazonECR) 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 AmazonEKS, ECS Amazon ou. AWS Fargate

  • Les produits payants basés sur des conteneurs assortis d'une tarification contractuelle et d'une intégration AWS License Manager doivent être déployés sur EKS AmazonECS, Amazon Anywhere, AWS Fargate Amazon EKS 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 de création AMI et d'utilisation du produit pour AWS Marketplace.

Exigences relatives aux produits EKS complémentaires Amazon

Un EKS module complémentaire Amazon est un logiciel qui fournit des fonctionnalités opérationnelles pour Kubernetes applications mais n'est pas spécifique à l'application. Par exemple, un EKS module complémentaire Amazon inclut des agents d'observabilité ou Kubernetes pilotes 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 AmazonEKS. Vous pouvez publier une version de votre produit en tant que AWS Marketplace module complémentaire dans le catalogue de EKS modules complémentaires Amazon. Votre module complémentaire apparaît dans la EKS console Amazon à côté des modules complémentaires gérés par d'autres fournisseurs AWS et par 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, consultez les EKSmodules complémentaires Amazon dans le guide de EKS l'utilisateur Amazon.

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 conçu de manière compatible avec AMD64 les deux ARM64 architectures.

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

    Note

    BYOLn'est pas pris en charge pour la livraison de EKS modules complémentaires Amazon.

  • Vous devez respecter toutes les exigences relatives aux produits liés au conteneur, y compris le transfert de toutes les images du conteneur et Helm graphiques dans les ECR référentiels Amazon AWS Marketplace 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 Gallery, Docker Hub, et Quay.

  • Helm graphiques - Préparez votre logiciel à déployer par le biais d'un Helm graphique. Le framework d'EKSextension Amazon convertit un Helm graphique dans un manifeste. Momentanée Helm les fonctionnalités ne sont pas prises en charge dans EKS les systèmes Amazon. La liste suivante décrit les exigences qui doivent être satisfaites avant l'intégration. Dans cette liste, tous Helm utilisation des commandes Helm version 3.8.1 :

    • Tous les Capabilities objets sont pris en charge, à l'exception de.APIVersions. .APIVersionsn'est pas pris en charge pour la non-built-in personnalisation Kubernetes APIs.

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

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

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

    • Le Helm le graphique doit passer avec succès Helm Lint et Helm Modèle sans erreur. Les commandes sont les suivantes :

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

      • Helm Modè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 AWS Marketplace Amazon ECR Repos. Pour créer un manifeste, utilisez Helm commande de modèle présentée précédemment. Recherchez dans le manifeste toute référence d'image externe, telle que busybox des gcr images. Téléchargez toutes les images de conteneur ainsi que les dépendances dans les ECR dépôts AWS Marketplace Amazon 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 manière d'identifier l'expérience utilisateur final, nommez le logiciel aws_mp_configuration_schema.json et mettez-le dans un emballage contenant le Helm graphique, voir EKSExtensions Amazon : Configuration avancée.

    Selon le mot clé « $schema », $schema il doit s'agir d'un mot 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 de pre-Add-on post-installation ou d'installation. Le produit ne doit pas dépendre de 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, le cas serviceAccount échéant — S'il s'agit d'un logiciel payant activé AWS Marketplace ou s'il doit être connecté à un autre Services AWS, assurez-vous que Helm le 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. Amazon EKS Addon Framework suit le déploiement de vos EKS ressources Amazon en les utilisant. 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 AMD et ARM architectures — De nombreux EKS clients Amazon utilisent ARM64 aujourd'hui des instances AWS Graviton. Les logiciels tiers doivent prendre en charge les deux architectures.

  • Intégrez les licences ou les compteurs APIs à partir de AWS Marketplace : AWS Marketplace prend en charge plusieurs modèles de facturation. Pour de plus amples informations, veuillez consulter Intégrations relatives à la facturation, au mesurage et aux licences des produits conteneurisés. Si vous souhaitez vendre votre produit par le biais de PAYG mécanismes, consultezConfiguration du comptage personnalisé pour les produits en conteneurs 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, par exemple, GitHub. Si le logiciel nécessite des dépendances externes, celles-ci doivent être transférées vers des ECR référentiels Amazon 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.

  • IAMrôles — Répertoriez toutes les AWS Identity and Access Management (IAM) politiques 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 sortie en amont. À mesure que les nouvelles versions EKS du cluster Amazon deviennent 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 EKS cluster Amazon. 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 licences et aux compteurs APIs pour les produits payants. BYOLles produits ne sont pas acceptés.

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

Amazon EKS exige une configuration sous forme de chaîne de JSONschéma Helm 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 API appels 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érances, etc. nodeSelector

  • Configurations spécifiques aux modules complémentaires, telles que la clé de licence, l'activation des fonctionnalitésURLs, 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 EKS modules complémentaires Amazon.

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

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 EKS modules complémentaires Amazon 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 l'ê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 EKS la console Amazon pour chaque paramètre de configuration.

RBACdéfinition

Les fournisseurs de modules complémentaires doivent définir et fournir les RBAC autorisations nécessaires pour installer correctement le module complémentaire en utilisant le principe du moindre privilège. Si RBAC les autorisations doivent être modifiées pour les nouvelles versions d'un module complémentaire ou pour toute correction visant à remédier à un problèmeCVE, les fournisseurs de modules complémentaires devront informer l'EKSéquipe Amazon 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 API clé, le mot de passe, etc. Amazon ne prend actuellement EKS APIs 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 ?
additionalLabels Ajoutez des étiquettes Kubernetes à tous les objets Kubernetes gérés par le module complémentaire. Non
additionalAnnotations Ajoutez des annotations Kubernetes à tous les objets Kubernetes gérés par le module complémentaire. Non
podLabels Ajoutez des étiquettes Kubernetes aux pods gérés par le module complémentaire. Non
podAnnotations 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
nodeSelector Forme recommandée la plus simple de contrainte de sélection de nœuds. Vous pouvez ajouter le nodeSelector champ à 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 nodeSelector champ, 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
topologySpreadConstraints 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, EBS CSI le pilote Amazon 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 JSON schéma 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 EKS service Amazon sera automatiquement injecté par les EKS modules complémentaires Amazon, et il n'incombe pas à l'utilisateur de le spécifier comme option de configuration. Ces paramètres incluent :

  • AWS région

  • Nom EKS du cluster Amazon

  • VPCID du cluster

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

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

  • Point de API terminaison EKS du cluster Amazon

  • IPv4activé sur le cluster

  • IPv6activé sur le cluster

  • Délégation de préfixe pour IPv6 activation 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 AmazonEKS. Les métadonnées de version spécifieront le mappage entre le parameterType et lename/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. Les paramètres tels que ceux ci-dessus qu'Amazon EKS doit 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
imagePullSecrets Configuration d'un pod pour utiliser un secret à extraire d'un registre privé. N/A
livenessProbe 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
readinessProbe 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
startupProbe 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
podDisruptionBudget Définissez un budget de désactivation des modules (PDB) afin de garantir qu'un nombre minimum de modules PODS continuent de fonctionner en cas d'interruptions volontaires. A 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
serviceAccount (annotations) Annotations appliquées au compte de service. Généralement utilisé pour la fonctionnalité IAM Rôles pour les comptes de service Non, le rôle IAM du compte de service ARN est défini dans les EKS modules complémentaires Amazon de haut niveauAPI. Il existe une exception à cette règle si votre module complémentaire comporte plusieurs déploiements/contrôleurs (tels que Flux) et nécessite un rôle distinct. IRSA ARNs
priorityClassName 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.
podSecurityContext 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 , ce qui était requis pour IRSA les clusters v1.19 et inférieurs. Peu probable, étant donné qu'Amazon EKS ne prend plus en charge Kubernetes v1.19
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. Oui
updateStrategy Spécifie la stratégie utilisée pour remplacer les anciens pods par de nouveaux. Oui
nameOverride Remplacez le nom des pods. Non
podSecurityPolicy

Appliquez des restrictions sur les paramètres.

 Non, PSPs sont déconseillés
extraVolumeMounts/extraVolumes

Utilisé IRSA dans les EKS clusters autres qu'Amazon.

Non