considérations relatives à Kro pour EKS - Amazon EKS
Quand utiliser KroModèles RBACIntégration avec d'autres fonctionnalités d'EKSOrganiser ResourceGraphDefinitionsVersionnage et mises à jourValidation et testsDocumentation en amontÉtapes suivantes

Aidez à améliorer cette page

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.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

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.

considérations relatives à Kro pour EKS

Cette rubrique aborde les considérations importantes relatives à l'utilisation de la fonctionnalité EKS pour kro, notamment le moment d'utiliser la composition des ressources, les modèles RBAC et l'intégration avec d'autres fonctionnalités EKS.

Quand utiliser Kro

kro est conçu pour créer des modèles d'infrastructure réutilisables et personnalisés APIs qui simplifient la gestion complexe des ressources.

Utilisez Kro lorsque vous devez :

  • Créez des plateformes en libre-service simplifiées APIs pour les équipes d'application

  • Standardisez les modèles d'infrastructure entre les équipes (base de données, sauvegarde et surveillance)

  • Gérez les dépendances des ressources et transmettez des valeurs entre les ressources

  • Créez des abstractions personnalisées qui masquent la complexité de l'implémentation

  • Composez plusieurs ressources ACK en blocs de construction de niveau supérieur

  • Activez GitOps les flux de travail pour les infrastructures complexes

N'utilisez pas kro lorsque :

  • Gestion de ressources simples et autonomes (utilisez directement les ressources ACK ou Kubernetes)

  • Vous avez besoin d'une logique d'exécution dynamique (kro est déclaratif, pas impératif)

  • Les ressources n'ont pas de dépendances ni de configuration partagée

kro excelle dans la création de « voies pavées », des modèles réutilisables et opiniâtres qui permettent aux équipes de déployer facilement et correctement des infrastructures complexes.

Modèles RBAC

kro permet de séparer les préoccupations entre les équipes de plateforme qui créent ResourceGraphDefinitions et les équipes d'application qui créent les instances.

Responsabilités de l'équipe de plateforme

Les équipes de la plateforme créent et gèrent ResourceGraphDefinitions (RGDs) qui définissent la personnalisation APIs.

Autorisations nécessaires :

  • Création, mise à jour, suppression ResourceGraphDefinitions

  • Gérer les types de ressources sous-jacents (déploiements, services, ressources ACK)

  • Accès à tous les espaces de noms où RGDs seront utilisés

Exemple ClusterRole pour l'équipe de la plateforme :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: platform-kro-admin
rules:
- apiGroups: ["kro.run"]
  resources: ["resourcegraphdefinitions"]
  verbs: ["*"]
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]

Pour une configuration RBAC détaillée, voirConfigurer les autorisations Kro.

Responsabilités de l'équipe de candidature

Les équipes d'application créent des instances de ressources personnalisées définies par RGDs sans avoir à comprendre la complexité sous-jacente.

Autorisations nécessaires :

  • Création, mise à jour, suppression d'instances de ressources personnalisées

  • Accès en lecture à leur espace de noms

  • Aucun accès aux ressources sous-jacentes ou RGDs

Avantages :

  • Les équipes utilisent des outils simples et de haut niveau APIs

  • Les équipes de plateforme contrôlent les détails de mise en œuvre

  • Réduction du risque de mauvaise configuration

  • Intégration plus rapide pour les nouveaux membres de l'équipe

Intégration avec d'autres fonctionnalités d'EKS

Composer des ressources ACK

kro est particulièrement puissant lorsqu'il est associé à ACK pour créer des modèles d'infrastructure.

Schémas courants :

  • Application avec stockage : compartiment S3 + file d'attente SQS + configuration des notifications

  • Pile de base de données : instance RDS + groupe de paramètres + groupe de sécurité + secret Secrets Manager

  • Mise en réseau : VPC + sous-réseaux + tables de routage + groupes de sécurité + passerelles NAT

  • Calcul avec stockage : EC2 instance + volumes EBS + profil d'instance IAM

kro gère l'ordre des dépendances, transmet les valeurs entre les ressources (chaînes similaires ARNs et chaînes de connexion) et gère le cycle de vie complet en tant qu'unité unique.

Pour des exemples de composition de ressources ACK, voirConcepts d'ACK.

GitOps avec Argo CD

Utilisez le CD EKS Capability for Argo pour déployer à la fois des instances RGDs et des instances à partir de référentiels Git.

Organisation du référentiel :

  • Dépôt de plateforme : contenus ResourceGraphDefinitions gérés par l'équipe de la plateforme

  • Dépôts d'applications : contiennent des instances de ressources personnalisées gérées par les équipes chargées des applications

  • Dépôt partagé : contient à la fois des instances RGDs et des instances pour les petites organisations

Considérations :

  • Déployez RGDs avant les instances (les ondes de synchronisation Argo CD peuvent vous aider)

  • Utilisez des projets Argo CD distincts pour les équipes chargées des plateformes et des applications

  • L'équipe de la plateforme contrôle l'accès au référentiel RGD

  • Les équipes chargées des applications ont un accès en lecture seule aux définitions RGD

Pour en savoir plus sur Argo CD, voirTravailler avec Argo CD.

Organiser ResourceGraphDefinitions

Organisez RGDs en fonction de l'objectif, de la complexité et de la propriété.

Par objectif :

  • Infrastructure : piles de bases de données, mise en réseau, stockage

  • Application : applications Web APIs, tâches par lots

  • Plateforme : services partagés, surveillance, journalisation

Par complexité :

  • Simple : 2 à 3 ressources avec un minimum de dépendances

  • Modéré : 5 à 10 ressources avec certaines dépendances

  • Complexe : plus de 10 ressources avec des dépendances complexes

Conventions de dénomination :

  • Utilisez des noms descriptifs :webapp-with-database, s3-notification-queue

  • Incluez la version dans le nom pour les modifications majeures : webapp-v2

  • Utilisez des préfixes cohérents pour les éléments suivants RGDs :platform- , app-

Stratégie d'espace de noms :

  • RGDs sont limités à la taille d'un cluster (et non à un espace de noms)

  • Les instances sont dotées d'un espace de noms

  • Utilisez des sélecteurs d'espaces de noms RGDs pour contrôler où les instances peuvent être créées

Versionnage et mises à jour

Planifiez l'évolution du RGD et la migration des instances.

Mises à jour du RGD :

  • Changements permanents : mettez à jour le RGD en place (ajoutez des champs facultatifs, de nouvelles ressources avec IncludeWhen)

  • Changements radicaux : créer un nouveau RGD avec un nom différent (webapp-v2)

  • Obsolète : Marquez les anciens RGDs avec des annotations, communiquez le calendrier de migration

Migration d'instance :

  • Créez de nouvelles instances avec un RGD mis à jour

  • Validez que les nouvelles instances fonctionnent correctement

  • Supprimer les anciennes instances

  • kro gère automatiquement les mises à jour des ressources sous-jacentes

Bonnes pratiques :

  • Testez d'abord les modifications du RGD dans des environnements hors production

  • Utiliser le versionnement sémantique dans les noms RGD pour les modifications majeures

  • Documenter les modifications majeures et les voies de migration

  • Fournir des exemples de migration pour les équipes chargées des applications

Validation et tests

Validez RGDs avant le déploiement en production.

Stratégies de validation :

  • Validation du schéma : kro valide automatiquement la structure RGD

  • Instances à sec : créez des instances de test dans les espaces de noms de développement

  • Tests d'intégration : vérifier que les ressources composées fonctionnent ensemble

  • Application des politiques : utilisez des contrôleurs d'admission pour faire appliquer les normes organisationnelles

Problèmes courants à tester :

  • Dépendances des ressources et classement

  • Transfert de valeur entre les ressources (expressions CEL)

  • Inclusion conditionnelle de ressources (IncludeWhen)

  • Propagation du statut à partir des ressources sous-jacentes

  • Autorisations RBAC pour la création d'instances

Documentation en amont

Pour des informations détaillées sur l'utilisation de kro :

Étapes suivantes