Considérations relatives aux fonctionnalités EKS

Cette rubrique aborde les considérations importantes relatives à l'utilisation des fonctionnalités EKS, notamment la conception du contrôle d'accès, le choix entre les fonctionnalités EKS et les solutions autogérées, les modèles architecturaux pour les déploiements multiclusters et les meilleures pratiques opérationnelles.

Fonctionnalité : rôles IAM et Kubernetes RBAC

Chaque ressource de capacité EKS possède un rôle IAM de fonctionnalité configuré. Le rôle de capacité est utilisé pour accorder des autorisations de AWS service permettant aux fonctionnalités EKS d'agir en votre nom. Par exemple, pour utiliser la fonctionnalité EKS pour ACK afin de gérer les compartiments Amazon S3, vous devez accorder à cette fonctionnalité des autorisations administratives lui permettant de créer et de gérer des compartiments.

Une fois la fonctionnalité configurée, les ressources S3 dans AWS peuvent être créées et gérées avec les ressources personnalisées Kubernetes de votre cluster. Kubernetes RBAC est le mécanisme de contrôle d'accès intégré au cluster qui permet de déterminer quels utilisateurs et groupes peuvent créer et gérer ces ressources personnalisées. Par exemple, accordez à des utilisateurs et à des groupes Kubernetes RBAC spécifiques des autorisations pour créer et gérer des Bucket ressources dans les espaces de noms de votre choix.

Ainsi, IAM et Kubernetes RBAC sont les deux moitiés du système de contrôle d' end-to-endaccès qui régit les autorisations liées aux capacités et aux ressources d'EKS. Il est important de concevoir la bonne combinaison d'autorisations IAM et de politiques d'accès RBAC pour votre cas d'utilisation.

Pour plus d'informations sur les fonctionnalités, les rôles IAM et les autorisations Kubernetes, consultez. Considérations relatives à la sécurité relatives aux fonctionnalités EKS

Modèles d'architecture multi-clusters

Lorsque vous déployez des fonctionnalités sur plusieurs clusters, tenez compte des modèles architecturaux courants suivants :

Hub and Spoke avec gestion centralisée

Exécutez les trois fonctionnalités dans un cluster géré de manière centralisée pour orchestrer les charges de travail et gérer l'infrastructure cloud sur plusieurs clusters de charge de travail.

• Argo CD sur le cluster de gestion déploie des applications sur des clusters de charge de travail situés dans différentes régions ou comptes

• ACK sur le cluster de gestion fournit des AWS ressources (RDS, S3, IAM) pour tous les clusters

• kro sur le cluster de gestion crée des abstractions de plate-forme portables qui fonctionnent sur tous les clusters

Ce modèle centralise la gestion de la charge de travail et de l'infrastructure cloud, et peut simplifier les opérations pour les entreprises qui gèrent de nombreux clusters.

Décentralisé GitOps

Les charges de travail et l'infrastructure cloud sont gérées par des fonctionnalités du même cluster sur lequel les charges de travail sont exécutées.

• Argo CD gère les ressources de l'application sur le cluster local.

• Les ressources ACK sont utilisées pour les besoins des clusters et des charges de travail.

• les abstractions de la plateforme kro sont installées et orchestrent les ressources locales.

Ce modèle décentralise les opérations, les équipes gérant leurs propres services de plateforme dédiés dans un ou plusieurs clusters.

Déploiement de Hub and Spoke avec Hybrid ACK

Combinez des modèles centralisés et décentralisés, avec des déploiements d'applications centralisés et une gestion des ressources en fonction du périmètre et de la propriété.

• Cluster central :

  • Argo CD gère les GitOps déploiements vers le cluster local et tous les clusters de charge de travail distants

  • ACK est utilisé sur le cluster de gestion pour les ressources administrées (bases de données de production, rôles IAM,) VPCs

  • kro est utilisé sur le cluster de gestion pour les abstractions de plateforme réutilisables

• Clusters de rayons :

  • Les charges de travail sont gérées via Argo CD sur le cluster centralisé

  • ACK est utilisé localement pour les ressources limitées à la charge de travail (compartiments S3, instances, ElastiCache files d'attente SQS)

  • kro est utilisé localement pour les compositions de ressources et les modèles de blocs de construction

Ce schéma distingue les préoccupations : les équipes chargées des plateformes gèrent les infrastructures critiques de manière centralisée sur des clusters de gestion, y compris éventuellement des clusters de charge de travail, tandis que les équipes chargées des applications spécifient et gèrent les ressources cloud parallèlement aux charges de travail.

Choisir un motif

Tenez compte des facteurs suivants lors du choix d'une architecture :

• Structure organisationnelle : les équipes centralisées privilégient les modèles de hub ; les équipes décentralisées peuvent préférer les capacités par cluster

• Étendue des ressources : les ressources réservées aux administrateurs (bases de données, IAM) bénéficient souvent d'une gestion centralisée ; les ressources de charge de travail (compartiments, files d'attente) peuvent être gérées localement

• Libre-service : les équipes centralisées de la plateforme peuvent créer et distribuer des ressources personnalisées prescriptives afin de permettre un libre-service sécurisé des ressources cloud pour les besoins de charge de travail courants

• Gestion du parc de clusters : les clusters de gestion centralisée fournissent un plan de contrôle appartenant au client pour la gestion du parc de clusters EKS, ainsi que d'autres ressources destinées aux administrateurs

• Exigences de conformité : certaines organisations ont besoin d'un contrôle centralisé pour l'audit et la gouvernance

• Complexité opérationnelle : la diminution du nombre d'instances de capacité simplifie les opérations mais peut créer des goulots d'étranglement

Note

Vous pouvez commencer avec un modèle et évoluer vers un autre au fur et à mesure que votre plateforme mûrit. Les fonctionnalités sont indépendantes : vous pouvez les déployer différemment entre les clusters en fonction de vos besoins.

Comparaison des fonctionnalités d'EKS avec les solutions autogérées

Les fonctionnalités EKS fournissent des expériences entièrement gérées pour les outils et contrôleurs Kubernetes les plus courants qui s'exécutent dans EKS. Cela diffère des solutions autogérées, que vous installez et exploitez dans votre cluster.

Principales différences

Déploiement et gestion

AWS gère entièrement les fonctionnalités EKS sans qu'aucune installation, configuration ou maintenance des composants logiciels ne soit requise. AWS installe et gère automatiquement toutes les définitions de ressources personnalisées Kubernetes (CRDs) requises dans le cluster.

Avec les solutions autogérées, vous installez et configurez un logiciel de cluster à l'aide de graphiques Helm, de kubectl ou d'autres opérateurs. Vous avez le contrôle total du cycle de vie des logiciels et de la configuration d'exécution de vos solutions autogérées, en fournissant des personnalisations à tous les niveaux de la solution.

Exploitation et maintenance

AWS gère les correctifs et autres opérations du cycle de vie des logiciels pour EKS Capabilities, avec des mises à jour automatiques et des correctifs de sécurité. Les fonctionnalités EKS sont intégrées à des AWS fonctionnalités pour des configurations rationalisées, offrent une haute disponibilité et une tolérance aux pannes intégrées, et éliminent le dépannage des charges de travail des contrôleurs au sein du cluster.

Les solutions autogérées vous obligent à surveiller l'état de santé et les journaux des composants, à appliquer des correctifs de sécurité et des mises à jour de version, à configurer la haute disponibilité avec plusieurs répliques et des budgets d'interruption des pods, à résoudre les problèmes de charge de travail des contrôleurs et à gérer les versions et les versions. Vous avez le contrôle total de vos déploiements, mais cela nécessite souvent des solutions sur mesure pour l'accès aux clusters privés et d'autres intégrations qui doivent être conformes aux normes organisationnelles et aux exigences de conformité en matière de sécurité.

Consommation de ressources

Les fonctionnalités EKS s'exécutent dans EKS et hors de vos clusters, libérant ainsi des ressources de nœud et de cluster. Les fonctionnalités n'utilisent pas les ressources de charge de travail du cluster, ne consomment ni le processeur ni la mémoire de vos nœuds de travail, évoluent automatiquement et ont un impact minimal sur la planification de la capacité du cluster.

Les solutions autogérées exécutent des contrôleurs et d'autres composants sur vos nœuds de travail, consommant ainsi directement les ressources des nœuds de travail IPs, du cluster et d'autres ressources du cluster. La gestion des services de cluster nécessite une planification des capacités pour leurs charges de travail, ainsi que la planification et la configuration des demandes de ressources et des limites afin de gérer les exigences de scalabilité et de haute disponibilité.

Support des fonctionnalités

En tant que fonctionnalités de service entièrement gérées, les fonctionnalités EKS Capabilities sont, par nature, bien ancrées par rapport aux solutions autogérées. Bien que les fonctionnalités soient compatibles avec la plupart des fonctionnalités et des cas d'utilisation, il y aura une différence de couverture par rapport aux solutions autogérées.

Avec les solutions autogérées, vous contrôlez entièrement la configuration, les fonctionnalités optionnelles et les autres aspects des fonctionnalités de votre logiciel. Vous pouvez choisir d'exécuter vos propres images personnalisées, de personnaliser tous les aspects de la configuration et de contrôler entièrement les fonctionnalités de votre solution autogérée.

Considérations relatives aux coûts

Chaque ressource de capacité EKS a un coût horaire associé, qui varie en fonction du type de capacité. Les ressources du cluster gérées par cette fonctionnalité ont également un coût horaire associé à leur propre tarification. Pour plus d’informations, consultez les tarifs Amazon EKS.

Les solutions autogérées n'ont aucun coût direct lié aux AWS frais, mais vous payez pour les ressources de calcul du cluster utilisées par les contrôleurs et les charges de travail associées. Au-delà de la consommation des ressources des nœuds et des clusters, le coût total de possession des solutions autogérées inclut les frais d'exploitation et les dépenses de maintenance, de dépannage et de support.

Choisir entre les fonctionnalités EKS et les solutions autogérées

Capacités d'EKS Envisagez ce choix lorsque vous souhaitez réduire les frais opérationnels et vous concentrer sur la valeur différenciée de vos logiciels et systèmes, plutôt que sur les opérations de plate-forme de cluster pour répondre à des exigences de base. Utilisez les fonctionnalités EKS lorsque vous souhaitez minimiser la charge opérationnelle liée aux correctifs de sécurité et à la gestion du cycle de vie des logiciels, libérer des ressources de nœuds et de clusters pour les charges de travail des applications, simplifier la configuration et la gestion de la sécurité, et bénéficier d'une couverture de AWS support. Les fonctionnalités EKS sont idéales pour la plupart des cas d'utilisation en production et constituent l'approche recommandée pour les nouveaux déploiements.

Solutions autogérées Envisagez ce choix lorsque vous avez besoin de versions spécifiques de l'API de ressources Kubernetes, de versions de contrôleurs personnalisées, de systèmes d'automatisation et d'outils existants basés sur des déploiements autogérés ou lorsque vous avez besoin d'une personnalisation approfondie des configurations d'exécution des contrôleurs. Les solutions autogérées offrent de la flexibilité pour les cas d'utilisation spécialisés et vous permettent de contrôler totalement votre déploiement et votre configuration d'exécution.

Note

Les fonctionnalités EKS peuvent coexister dans votre cluster avec des solutions autogérées, et des migrations par étapes sont possibles.

Comparaisons spécifiques aux capacités

Pour des comparaisons détaillées, notamment les fonctionnalités spécifiques aux capacités, les différences en amont et les chemins de migration, voir :

• Comparaison de la capacité EKS pour ACK à une solution ACK autogérée

• Comparaison de la fonctionnalité EKS pour Argo CD à celle d'Argo CD autogéré

• Comparaison entre la capacité EKS pour kro et celle pour kro autogérée