View a markdown version of this page

considérations relatives à Kro pour EKS - Amazon EKS
Quand utiliser KroModèles RBACIntégration avec d'autres fonctionnalités d'EKSOrganisation 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

Passez en revue les considérations importantes relatives à l'utilisation de la fonctionnalité gérée 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 des API personnalisées qui simplifient la gestion complexe des ressources.

Utilisez Kro lorsque vous devez :

  • Créez des plateformes en libre-service avec des API simplifiées pour les équipes chargées des applications

  • 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 la mise en œuvre

  • 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 maintiennent ResourceGraphDefinitions (RGD) qui définissent des API personnalisées.

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ù les RGD 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 aux RGD

Avantages :

  • Les équipes utilisent des API simples et de haut niveau

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

Modèles 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 : instance EC2 + volumes EBS + profil d'instance IAM

kro gère l'ordre des dépendances, transmet les valeurs entre les ressources (comme les ARN et les 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 RGD 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 RGD et des instances pour les petites organisations

Considérations :

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

  • Utilisez des projets Argo CD distincts pour les équipes chargées de la plateforme et de l'application

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

Organisation ResourceGraphDefinitions

Organisez les RGD par objectif, complexité et propriété.

Par objectif :

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

  • Application : applications Web, API, 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 RGD associés :, platform- app-

Stratégie d'espace de noms :

  • Les RGD sont limités à un cluster (et non à un espace de noms)

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

  • Utilisez les sélecteurs d'espace de noms dans les RGD 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 :

  • Non-breaking modifications : mise à jour du RGD en place (ajout de champs facultatifs, nouvelles ressources avec IncludeWhen)

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

  • Obsolète : marquez les anciens RGD 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 les RGD avant de les déployer en production.

Stratégies de validation :

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

  • Dry-run instances : créer 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