**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.
# Composition des ressources avec kro (Kube Resource Orchestrator)
**kro (Kube Resource Orchestrator)** est un projet open source natif de Kubernetes qui vous permet de définir des Kubernetes personnalisés à l'aide d'une configuration simple et directe. APIs Avec kro, vous pouvez facilement configurer de nouvelles personnalisations APIs qui créent un groupe d'objets Kubernetes et les opérations logiques entre eux.
Grâce aux fonctionnalités d'EKS, Kro est entièrement géré par AWS, ce qui élimine le besoin d'installer, de maintenir et de dimensionner les contrôleurs Kro sur vos clusters.
## Comment fonctionne Kro
kro introduit une définition de ressource personnalisée (CRD) appelée `ResourceGraphDefinition` (RGD) qui permet de créer des Kubernetes personnalisés de manière simple et rationalisée. APIs Lorsque vous créez un`ResourceGraphDefinition`, kro utilise des extensions Kubernetes natives pour créer et gérer de nouvelles APIs extensions dans votre cluster. À partir de cette spécification de ressource unique, kro créera et enregistrera un nouveau CRD pour vous en fonction de votre spécification et s'adaptera pour gérer vos ressources personnalisées nouvellement définies.
RGDs peut inclure plusieurs ressources, et kro déterminera les interdépendances et l'ordre des ressources, pour que vous n'ayez pas à le faire. Vous pouvez utiliser une syntaxe simple pour injecter de la configuration d'une ressource à l'autre, ce qui simplifie considérablement les compositions et élimine le besoin d'opérateurs de « colle » dans votre cluster. Avec kro, vos ressources personnalisées peuvent inclure des ressources Kubernetes natives ainsi que toutes les définitions de ressources personnalisées (CRDs) installées dans le cluster.
kro prend en charge un seul type de ressource principale :
+ **ResourceGraphDefinition (RGD)** : définit une ressource personnalisée Kubernetes, encapsulant une ou plusieurs ressources Kubernetes natives ou personnalisées sous-jacentes
En plus de cette ressource, kro créera et gérera le cycle de vie de vos ressources personnalisées créées avec elle, ainsi que de toutes les ressources qui les constituent.
kro s'intègre parfaitement à AWS Controllers for Kubernetes (ACK), ce qui vous permet de composer des ressources de charge de travail avec des ressources pour créer des abstractions de AWS haut niveau. Cela vous permet de créer vos propres éléments constitutifs du cloud, de simplifier la gestion des ressources et d'activer des modèles réutilisables avec des paramètres de configuration par défaut et immuables basés sur les normes de votre organisation.
## Les avantages de Kro
kro permet aux équipes de plateforme de créer des Kubernetes personnalisés APIs qui composent plusieurs ressources en abstractions de niveau supérieur. Cela simplifie la gestion des ressources en permettant aux développeurs de déployer des applications complexes à l'aide de ressources personnalisées simples, standardisées et versionnées. Vous définissez des modèles réutilisables pour les combinaisons de ressources communes, ce qui permet une création de ressources cohérente au sein de votre organisation.
kro utilise le [langage d'expression commun (CEL) dans Kubernetes](https://kubernetes.io/docs/reference/using-api/cel/) pour transmettre des valeurs entre les ressources et intégrer une logique conditionnelle, offrant ainsi une flexibilité dans la composition des ressources. Vous pouvez composer à la fois les ressources Kubernetes et les AWS ressources gérées par ACK de manière personnalisée unifiée APIs, ce qui permet de définir des applications et des infrastructures complètes.
kro prend en charge la configuration déclarative via les manifestes Kubernetes, ce qui permet aux GitOps flux de travail et à l'infrastructure de devenir des pratiques de code qui s'intègrent parfaitement à vos processus de développement existants. Dans le cadre des fonctionnalités gérées par EKS, kro est entièrement géré par AWS, ce qui élimine le besoin d'installer, de configurer et de maintenir des contrôleurs kro sur vos clusters.
**Exemple : création d'un ResourceGraphDefinition**
L'exemple suivant montre une application simple `ResourceGraphDefinition` qui crée une application Web avec un déploiement et un service :
```
apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
name: web-application
spec:
schema:
apiVersion: v1alpha1
kind: WebApplication
spec:
name: string
replicas: integer | default=3
resources:
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
metadata:
name: ${schema.spec.name}
spec:
replicas: ${schema.spec.replicas}
- id: service
template:
apiVersion: v1
kind: Service
metadata:
name: ${schema.spec.name}
```
Lorsque les utilisateurs créent des instances de la ressource `WebApplication` personnalisée, kro crée automatiquement les ressources de déploiement et de service correspondantes, en gérant leur cycle de vie ainsi que la ressource personnalisée.
## Intégration avec d'autres fonctionnalités gérées par EKS
kro s'intègre aux autres fonctionnalités gérées par EKS.
+ ** AWS Contrôleurs pour Kubernetes (ACK)** : utilisez kro pour composer les ressources ACK en abstractions de niveau supérieur, simplifiant ainsi la gestion des ressources. AWS
+ **Argo CD** : utilisez Argo CD pour gérer le déploiement de ressources personnalisées Kro sur plusieurs clusters, en activant des GitOps flux de travail pour les éléments constitutifs de votre plate-forme et les piles d'applications.
## Débuter avec Kro
Pour commencer à utiliser la fonctionnalité EKS pour Kro :
1. [Créez une ressource de capacité Kro](create-kro-capability.md) sur votre cluster EKS via la AWS console, la AWS CLI ou votre infrastructure préférée en tant qu'outil de code.
1. Créez ResourceGraphDefinitions (RGDs) qui définit vos compositions personnalisées APIs et vos compositions de ressources.
1. Appliquez des instances de vos ressources personnalisées pour provisionner et gérer les Kubernetes et les ressources sous-jacentes. AWS
# Création d'une fonctionnalité Kro
Cette rubrique explique comment créer une fonctionnalité Kro sur votre cluster Amazon EKS.
## Conditions préalables
Avant de créer une fonctionnalité Kro, assurez-vous de disposer des éléments suivants :
+ Un cluster Amazon EKS existant exécutant une version de Kubernetes prise en charge (toutes les versions du support standard et étendu sont prises en charge)
+ Autorisations IAM suffisantes pour créer des ressources de capacités sur les clusters EKS
+ (Pour CLI/ekSCTL) L'outil CLI approprié est installé et configuré
**Note**
Contrairement à ACK et Argo CD, kro n'a pas besoin d'autorisations IAM supplémentaires au-delà de la politique de confiance. kro fonctionne entièrement au sein de votre cluster et n'effectue pas d'appels d'API. AWS Cependant, vous devez tout de même fournir un rôle de capacité IAM avec la politique de confiance appropriée. Pour plus d'informations sur la configuration des autorisations RBAC de Kubernetes pour kro, consultez. [Configurer les autorisations Kro](kro-permissions.md)
## Choisissez votre outil
Vous pouvez créer une fonctionnalité kro à l'aide de la AWS Management Console AWS CLI ou de eksctl :
+ [Création d'une fonctionnalité Kro à l'aide de la console](kro-create-console.md)- Utilisez la console pour une expérience guidée
+ [Création d'une fonctionnalité Kro à l'aide de la CLI AWS](kro-create-cli.md)- Utilisez la AWS CLI pour la création de scripts et l'automatisation
+ [Création d'une capacité kro à l'aide de eksctl](kro-create-eksctl.md)- Utilisez eksctl pour une expérience native de Kubernetes
## Que se passe-t-il lorsque vous créez une capacité Kro
Lorsque vous créez une fonctionnalité Kro :
1. EKS crée le service Kro Capability et le configure pour surveiller et gérer les ressources de votre cluster
1. Des définitions de ressources personnalisées (CRDs) sont installées dans votre cluster
1. Une entrée d'accès est automatiquement créée pour votre rôle de capacité IAM, `AmazonEKSKROPolicy` qui accorde les autorisations de gestion ResourceGraphDefinitions et de gestion de leurs instances (voir[Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md))
1. La fonctionnalité assume le rôle de capacité IAM que vous fournissez (utilisé uniquement pour la relation de confiance)
1. kro commence à surveiller les `ResourceGraphDefinition` ressources et leurs instances
1. L'état de capacité passe de `CREATING` à `ACTIVE`
Une fois actif, vous pouvez créer ResourceGraphDefinitions pour définir des paramètres personnalisés APIs et créer des instances de ceux-ci APIs.
**Note**
L'entrée d'accès créée automatiquement inclut celle `AmazonEKSKROPolicy` qui accorde à Kro les autorisations de gestion ResourceGraphDefinitions et leurs instances. Pour permettre à kro de créer les ressources Kubernetes sous-jacentes définies dans vos fichiers ResourceGraphDefinitions (telles que les déploiements, les services ou les ressources ACK), vous devez configurer des politiques d'entrée d'accès supplémentaires. Pour en savoir plus sur les entrées d'accès et sur la façon de configurer des autorisations supplémentaires, consultez [Configurer les autorisations Kro](kro-permissions.md) et[Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md).
## Étapes suivantes
Après avoir créé la fonctionnalité Kro :
+ [concepts kro](kro-concepts.md)- Comprendre les concepts Kro et la composition des ressources
+ [concepts kro](kro-concepts.md)- En savoir plus sur SimpleSchema les expressions CEL et les modèles de composition des ressources
# Création d'une fonctionnalité Kro à l'aide de la console
Cette rubrique décrit comment créer une fonctionnalité kro (Kube Resource Orchestrator) à l'aide du. AWS Management Console
## Création de la fonctionnalité Kro
1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Sélectionnez le nom de votre cluster pour ouvrir la page détaillée du cluster.
1. Choisissez l'onglet **Fonctionnalités**.
1. Dans le volet de navigation de gauche, choisissez **kro (Kube Resource Orchestrator**).
1. Choisissez **Create Kro Capability.**
1. Pour le **rôle de capacité IAM** :
+ Si vous possédez déjà un rôle de capacité IAM, sélectionnez-le dans le menu déroulant
+ Si vous devez créer un rôle, choisissez **Create kro** role
Cela ouvre la console IAM dans un nouvel onglet avec une politique de confiance préremplie. Le rôle ne nécessite aucune autorisation IAM supplémentaire puisque kro fonctionne entièrement au sein de votre cluster.
Après avoir créé le rôle, retournez à la console EKS et le rôle sera automatiquement sélectionné.
**Note**
Contrairement à ACK et Argo CD, kro n'a pas besoin d'autorisations IAM supplémentaires au-delà de la politique de confiance. kro fonctionne entièrement au sein de votre cluster et n'effectue pas d'appels d'API. AWS
1. Choisissez **Créer**.
Le processus de création de capacités commence.
## Vérifiez que la fonctionnalité est active
1. Dans l'onglet **Capabilities**, consultez l'état des capacités Kro.
1. Attendez que le statut passe de `CREATING` à`ACTIVE`.
1. Une fois active, la fonctionnalité est prête à être utilisée.
Pour plus d'informations sur l'état des fonctionnalités et le dépannage, consultez[Utilisation des ressources en matière de capacités](working-with-capabilities.md).
## Accorder des autorisations pour gérer les ressources Kubernetes
Lorsque vous créez une fonctionnalité kro, une entrée d'accès EKS est automatiquement créée avec le`AmazonEKSKROPolicy`, ce qui permet à kro de gérer ses ResourceGraphDefinitions instances. Cependant, aucune autorisation n'est accordée par défaut pour créer les ressources Kubernetes sous-jacentes (telles que les déploiements, les services ConfigMaps, etc.) définies dans votre. ResourceGraphDefinitions
Cette conception intentionnelle suit le principe du moindre privilège : différents nécessitent des autorisations différentes ResourceGraphDefinitions . Vous devez configurer explicitement les autorisations dont Kro a besoin en fonction des ressources que vous ResourceGraphDefinitions allez gérer.
Pour une mise en route rapide, des environnements de test ou de développement, utilisez `AmazonEKSClusterAdminPolicy` :
1. Dans la console EKS, accédez à l'onglet **Accès** de votre cluster.
1. Sous **Entrées d'accès**, recherchez l'entrée correspondant à votre rôle de capacité Kro (il comportera l'ARN du rôle que vous avez créé précédemment).
1. Choisissez l'entrée d'accès pour en ouvrir les détails.
1. Dans la section **Politiques d'accès**, choisissez **Politique d'accès associée**.
1. Sélectionnez `AmazonEKSClusterAdminPolicy` dans la liste des politiques.
1. Pour **Etendue d'accès**, sélectionnez **Cluster**.
1. Choisissez **Associer**.
**Important**
Il `AmazonEKSClusterAdminPolicy` accorde des autorisations étendues pour créer et gérer toutes les ressources Kubernetes, y compris la possibilité de créer n'importe quel type de ressource dans tous les espaces de noms. C'est pratique pour le développement POCs mais ne doit pas être utilisé en production. Pour la production, créez des politiques RBAC personnalisées qui n'accordent que les autorisations nécessaires pour les ressources spécifiques que vous ResourceGraphDefinitions allez gérer. Pour obtenir des conseils sur la configuration des autorisations de moindre privilège, reportez-vous [Configurer les autorisations Kro](kro-permissions.md) aux sections et. [Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md)
## Vérifiez que les ressources personnalisées sont disponibles
Une fois la fonctionnalité activée, vérifiez que les ressources personnalisées kro sont disponibles dans votre cluster.
**Utilisation de la console**
1. Accédez à votre cluster dans la console Amazon EKS
1. Choisissez l'onglet **Ressources**
1. Choisissez les **extensions**
1. Choisissez **CustomResourceDefinitions**
Vous devriez voir le type de `ResourceGraphDefinition` ressource répertorié.
**Utilisation de kubectl**
```
kubectl api-resources | grep kro.run
```
Vous devriez voir le type de `ResourceGraphDefinition` ressource répertorié.
## Étapes suivantes
+ [concepts kro](kro-concepts.md)- Comprendre les concepts Kro et la composition des ressources
+ [concepts kro](kro-concepts.md)- En savoir plus sur SimpleSchema les expressions CEL et les modèles de composition
+ [Utilisation des ressources en matière de capacités](working-with-capabilities.md)- Gérez votre ressource Kro Capability
# Création d'une fonctionnalité Kro à l'aide de la CLI AWS
Cette rubrique décrit comment créer une fonctionnalité kro (Kube Resource Orchestrator) à l'aide de la CLI. AWS
## Conditions préalables
+ ** AWS CLI** : version `2.12.3` ou ultérieure. Pour vérifier votre version, lancez`aws --version`. Pour plus d'informations, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dans le guide de l'utilisateur de l'interface de ligne de AWS commande.
+ ** `kubectl` ** : outil de ligne de commande pour travailler avec des clusters Kubernetes. Pour de plus amples informations, veuillez consulter [Configuration de `kubectl` et `eksctl`](install-kubectl.md).
## Étape 1 : Création d'un rôle de capacité IAM
Créez un fichier de politique de confiance :
```
cat > kro-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Créez le rôle IAM :
```
aws iam create-role \
--role-name KROCapabilityRole \
--assume-role-policy-document file://kro-trust-policy.json
```
**Note**
Contrairement à ACK et Argo CD, kro ne nécessite pas d'autorisations IAM supplémentaires. kro fonctionne entièrement au sein de votre cluster et n'effectue pas d'appels d'API. AWS Le rôle est uniquement nécessaire pour établir une relation de confiance avec le service des capacités EKS.
## Étape 2 : Création de la fonctionnalité Kro
Créez la ressource de capacité Kro sur votre cluster. *region-code*Remplacez-le par la AWS région où se trouve votre cluster (par exemple`us-west-2`) et *my-cluster* par le nom de votre cluster.
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro \
--type KRO \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/KROCapabilityRole \
--delete-propagation-policy RETAIN
```
La commande revient immédiatement, mais la fonctionnalité met un certain temps à devenir active car EKS crée l'infrastructure de capacités et les composants requis. EKS installera les définitions de ressources personnalisées Kubernetes associées à cette fonctionnalité dans votre cluster lors de sa création.
**Note**
Si vous recevez un message d'erreur indiquant que le cluster n'existe pas ou que vous n'êtes pas autorisé, vérifiez :
Le nom du cluster est correct
Votre AWS CLI est configurée pour la bonne région
Vous disposez des autorisations IAM requises
## Étape 3 : vérifier que la fonctionnalité est active
Attendez que la fonctionnalité soit activée. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster et remplacez *my-cluster* par le nom de votre cluster.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro \
--query 'capability.status' \
--output text
```
La fonctionnalité est prête lorsque l'état s'affiche`ACTIVE`.
Vous pouvez également consulter les détails complets des fonctionnalités :
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro
```
## Étape 4 : octroyer des autorisations pour gérer les ressources Kubernetes
Lorsque vous créez une fonctionnalité kro, une entrée d'accès EKS est automatiquement créée avec le`AmazonEKSKROPolicy`, ce qui permet à kro de gérer ses ResourceGraphDefinitions instances. Cependant, aucune autorisation n'est accordée par défaut pour créer les ressources Kubernetes sous-jacentes (telles que les déploiements, les services ConfigMaps, etc.) définies dans votre. ResourceGraphDefinitions
Cette conception intentionnelle suit le principe du moindre privilège : différents nécessitent des autorisations différentes ResourceGraphDefinitions . Par exemple :\$1 A ResourceGraphDefinition qui crée uniquement ConfigMaps et Secrets a besoin d'autorisations différentes de celles qui créent des déploiements et des services \$1 A ResourceGraphDefinition qui crée des ressources ACK a besoin d'autorisations pour ces ressources personnalisées spécifiques \$1 Certains ResourceGraphDefinitions peuvent uniquement lire les ressources existantes sans en créer de nouvelles
Vous devez configurer explicitement les autorisations dont Kro a besoin en fonction des ressources que vous ResourceGraphDefinitions allez gérer.
### Configuration rapide
Pour démarrer rapidement, tester ou développer des environnements, utilisez `AmazonEKSClusterAdminPolicy` :
Obtenez l'ARN du rôle de capacité :
```
CAPABILITY_ROLE_ARN=$(aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro \
--query 'capability.roleArn' \
--output text)
```
Associez la politique d'administration du cluster :
```
aws eks associate-access-policy \
--region region-code \
--cluster-name my-cluster \
--principal-arn $CAPABILITY_ROLE_ARN \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
--access-scope type=cluster
```
**Important**
Il `AmazonEKSClusterAdminPolicy` accorde des autorisations étendues pour créer et gérer toutes les ressources Kubernetes, y compris la possibilité de créer n'importe quel type de ressource dans tous les espaces de noms. C'est pratique pour le développement POCs mais ne doit pas être utilisé en production. Pour la production, créez des politiques RBAC personnalisées qui n'accordent que les autorisations nécessaires pour les ressources spécifiques que vous ResourceGraphDefinitions allez gérer. Pour obtenir des conseils sur la configuration des autorisations de moindre privilège, reportez-vous [Configurer les autorisations Kro](kro-permissions.md) aux sections et. [Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md)
## Étape 5 : vérifier que les ressources personnalisées sont disponibles
Une fois la fonctionnalité activée, vérifiez que les ressources personnalisées kro sont disponibles dans votre cluster :
```
kubectl api-resources | grep kro.run
```
Vous devriez voir le type de `ResourceGraphDefinition` ressource répertorié.
## Étapes suivantes
+ [concepts kro](kro-concepts.md)- Comprendre les concepts Kro et la composition des ressources
+ [concepts kro](kro-concepts.md)- En savoir plus sur SimpleSchema les expressions CEL et les modèles de composition
+ [Utilisation des ressources en matière de capacités](working-with-capabilities.md)- Gérez votre ressource Kro Capability
# Création d'une capacité kro à l'aide de eksctl
Cette rubrique décrit comment créer une fonctionnalité kro (Kube Resource Orchestrator) à l'aide de eksctl.
**Note**
Les étapes suivantes nécessitent la version eksctl `0.220.0` ou une version ultérieure. Pour vérifier votre version, lancez`eksctl version`.
## Étape 1 : Création d'un rôle de capacité IAM
Créez un fichier de politique de confiance :
```
cat > kro-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Créez le rôle IAM :
```
aws iam create-role \
--role-name KROCapabilityRole \
--assume-role-policy-document file://kro-trust-policy.json
```
**Note**
Contrairement à ACK et Argo CD, kro n'a pas besoin d'autorisations IAM supplémentaires au-delà de la politique de confiance. kro fonctionne entièrement au sein de votre cluster et n'effectue pas d'appels d'API. AWS
## Étape 2 : Création de la fonctionnalité Kro
Créez la capacité kro à l'aide de eksctl. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster et remplacez *my-cluster* par le nom de votre cluster.
```
eksctl create capability \
--region region-code \
--cluster my-cluster \
--name my-kro \
--type KRO \
--role-arn arn:aws:iam::[.replaceable]111122223333:role/KROCapabilityRole
```
La commande revient immédiatement, mais la fonctionnalité met un certain temps à devenir active.
## Étape 3 : vérifier que la fonctionnalité est active
Vérifiez l'état des capacités. Remplacez *region-code* par la AWS région dans laquelle se trouve votre cluster et remplacez *my-cluster* par le nom de votre cluster.
```
eksctl get capability \
--region region-code \
--cluster my-cluster \
--name my-kro
```
La fonctionnalité est prête lorsque l'état s'affiche`ACTIVE`.
## Étape 4 : accorder des autorisations pour gérer les ressources Kubernetes
Par défaut, kro peut uniquement créer ResourceGraphDefinitions et gérer leurs instances. Pour permettre à kro de créer et de gérer les ressources Kubernetes sous-jacentes définies dans votre fichier ResourceGraphDefinitions, associez la politique d'`AmazonEKSClusterAdminPolicy`accès à l'entrée d'accès de la fonctionnalité.
Obtenez l'ARN du rôle de capacité :
```
CAPABILITY_ROLE_ARN=$(aws eks describe-capability \
--region region-code \
--cluster my-cluster \
--name my-kro \
--query 'capability.roleArn' \
--output text)
```
Associez la politique d'administration du cluster :
```
aws eks associate-access-policy \
--region region-code \
--cluster my-cluster \
--principal-arn $CAPABILITY_ROLE_ARN \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
--access-scope type=cluster
```
**Important**
Il `AmazonEKSClusterAdminPolicy` accorde des autorisations étendues pour créer et gérer toutes les ressources Kubernetes et vise à rationaliser le démarrage. Pour une utilisation en production, créez des politiques RBAC plus restrictives qui n'accordent que les autorisations nécessaires pour les ressources spécifiques que vous ResourceGraphDefinitions allez gérer. Pour obtenir des conseils sur la configuration des autorisations de moindre privilège, reportez-vous [Configurer les autorisations Kro](kro-permissions.md) aux sections et. [Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md)
## Étape 5 : vérifier que les ressources personnalisées sont disponibles
Une fois la fonctionnalité activée, vérifiez que les ressources personnalisées kro sont disponibles dans votre cluster :
```
kubectl api-resources | grep kro.run
```
Vous devriez voir le type de `ResourceGraphDefinition` ressource répertorié.
## Étapes suivantes
+ [concepts kro](kro-concepts.md)- Comprendre les concepts Kro et la composition des ressources
+ [concepts kro](kro-concepts.md)- En savoir plus sur SimpleSchema les expressions CEL et les modèles de composition
+ [Utilisation des ressources en matière de capacités](working-with-capabilities.md)- Gérez votre ressource Kro Capability
# concepts kro
kro permet aux équipes de plateforme de créer des Kubernetes personnalisés APIs qui composent plusieurs ressources en abstractions de niveau supérieur. Cette rubrique présente un exemple pratique, puis explique les concepts de base que vous devez comprendre lorsque vous travaillez avec la capacité EKS pour kro.
## Débuter avec Kro
Après avoir créé la fonctionnalité Kro (voir[Création d'une fonctionnalité Kro](create-kro-capability.md)), vous pouvez commencer à créer une APIs utilisation personnalisée ResourceGraphDefinitions dans votre cluster.
Voici un exemple complet qui crée une abstraction d'application Web simple :
```
apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
name: webapplication
spec:
schema:
apiVersion: v1alpha1
kind: WebApplication
group: kro.run
spec:
name: string | required=true
image: string | default="nginx:latest"
replicas: integer | default=3
resources:
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
metadata:
name: ${schema.spec.name}
spec:
replicas: ${schema.spec.replicas}
selector:
matchLabels:
app: ${schema.spec.name}
template:
metadata:
labels:
app: ${schema.spec.name}
spec:
containers:
- name: app
image: ${schema.spec.image}
ports:
- containerPort: 80
- id: service
template:
apiVersion: v1
kind: Service
metadata:
name: ${schema.spec.name}
spec:
selector:
app: ${schema.spec.name}
ports:
- protocol: TCP
port: 80
targetPort: 80
```
Après avoir appliqué cela ResourceGraphDefinition, les équipes d'application peuvent créer des applications Web à l'aide de votre API simplifiée :
```
apiVersion: kro.run/v1alpha1
kind: WebApplication
metadata:
name: my-app
spec:
name: my-app
replicas: 5
```
kro crée automatiquement le déploiement et le service avec la configuration appropriée. Comme il `image` n'est pas spécifié, il utilise la valeur par défaut `nginx:latest` du schéma.
## Concepts de base
**Important**
kro valide ResourceGraphDefinitions au moment de la création, pas au moment de l'exécution. Lorsque vous créez un RGD, kro valide la syntaxe du CEL, vérifie le type des expressions par rapport aux schémas Kubernetes réels, vérifie l'existence des champs et détecte les dépendances circulaires. Cela signifie que les erreurs sont détectées immédiatement lorsque vous créez le RGD, avant que les instances ne soient déployées.
### ResourceGraphDefinition
A ResourceGraphDefinition (RGD) définit une API Kubernetes personnalisée en spécifiant :
+ **Schéma** : structure de l'API à l'aide SimpleSchema du format (noms de champs, types, valeurs par défaut, validation)
+ **Ressources** : modèles pour les Kubernetes sous-jacents ou AWS ressources à créer
+ **Dépendances** - Comment les ressources sont liées les unes aux autres (détectée automatiquement à partir des références aux champs)
Lorsque vous appliquez un RGD, kro enregistre une nouvelle définition de ressource personnalisée (CRD) dans votre cluster. Les équipes d'application peuvent ensuite créer des instances de votre API personnalisée, et kro se charge de créer et de gérer toutes les ressources sous-jacentes.
Pour plus d'informations, consultez la section [ResourceGraphDefinition Présentation](https://kro.run/docs/concepts/rgd/overview/) dans la documentation de kro.
### SimpleSchema format
SimpleSchema fournit un moyen simplifié de définir des schémas d'API sans avoir besoin de connaissances d'OpenAPI :
```
schema:
apiVersion: v1alpha1
kind: Database
spec:
name: string | required=true description="Database name"
size: string | default="small" enum=small,medium,large
replicas: integer | default=1 minimum=1 maximum=5
```
SimpleSchema prend en charge `string` `integer``boolean`,, et `number` types avec des contraintes telles que `required``default`,`maximum`,`minimum`/`enum`, et`pattern`.
Pour plus d'informations, consultez [SimpleSchema](https://kro.run/docs/concepts/rgd/schema/)la documentation de kro.
### Expressions CEL
kro utilise le langage d'expression commun (CEL) pour référencer les valeurs de manière dynamique et ajouter une logique conditionnelle. Les expressions CEL sont encapsulées `${` `}` et peuvent être utilisées de deux manières :
**Expressions autonomes** - La valeur complète du champ est une expression unique :
```
spec:
replicas: ${schema.spec.replicaCount} # Expression returns integer
labels: ${schema.spec.labelMap} # Expression returns object
```
Le résultat de l'expression remplace la valeur complète du champ et doit correspondre au type attendu du champ.
**Modèles de chaînes** : une ou plusieurs expressions incorporées dans une chaîne :
```
metadata:
name: "${schema.spec.prefix}-${schema.spec.name}" # Multiple expressions
annotation: "Created by ${schema.spec.owner}" # Single expression in string
```
Toutes les expressions des modèles de chaînes doivent renvoyer des chaînes. `string()`À utiliser pour convertir d'autres types :`"replicas-${string(schema.spec.count)}"`.
**Références de champs** - Accédez aux valeurs des spécifications de l'instance à l'aide `schema.spec` de :
```
template:
metadata:
name: ${schema.spec.name}-deployment
namespace: ${schema.metadata.namespace} # Can also reference metadata
spec:
replicas: ${schema.spec.replicas}
```
**Accès aux champs facultatif - À** utiliser `?` pour les champs qui n'existent peut-être pas :
```
# For ConfigMaps or Secrets with unknown structure
value: ${configmap.data.?DATABASE_URL}
# For optional status fields
ready: ${deployment.status.?readyReplicas > 0}
```
Si le champ n'existe pas, l'expression est renvoyée `null` au lieu d'échouer.
**Ressources conditionnelles** - N'incluez les ressources que lorsque les conditions sont remplies :
```
resources:
- id: ingress
includeWhen:
- ${schema.spec.enableIngress == true}
template:
# ... ingress configuration
```
Le `includeWhen` champ accepte une liste d'expressions booléennes. Toutes les conditions doivent être remplies pour que la ressource soit créée. Actuellement, seuls `includeWhen` les `schema.spec` champs peuvent être référencés.
**Transformations** - Transformez les valeurs à l'aide d'opérateurs et de fonctions ternaires :
```
template:
spec:
resources:
requests:
memory: ${schema.spec.size == "small" ? "512Mi" : "2Gi"}
# String concatenation
image: ${schema.spec.registry + "/" + schema.spec.imageName}
# Type conversion
port: ${string(schema.spec.portNumber)}
```
**Références entre ressources** : valeurs de référence provenant d'autres ressources :
```
resources:
- id: bucket
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
spec:
name: ${schema.spec.name}-data
- id: configmap
template:
apiVersion: v1
kind: ConfigMap
data:
BUCKET_NAME: ${bucket.spec.name}
BUCKET_ARN: ${bucket.status.ackResourceMetadata.arn}
```
Lorsque vous référencez une autre ressource dans une expression CEL, cela crée automatiquement une dépendance. kro s'assure que la ressource référencée est créée en premier.
Pour plus d'informations, consultez la section [Expressions CEL](https://kro.run/docs/concepts/rgd/cel-expressions/) dans la documentation de kro.
### Dépendances des ressources
kro déduit automatiquement les dépendances à partir des expressions CEL : vous ne spécifiez pas l'ordre, vous décrivez les relations. Lorsqu'une ressource en référence une autre à l'aide d'une expression CEL, kro crée une dépendance et détermine l'ordre de création correct.
```
resources:
- id: bucket
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
spec:
name: ${schema.spec.name}-data
- id: notification
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: BucketNotification
spec:
bucket: ${bucket.spec.name} # Creates dependency: notification depends on bucket
```
L'expression `${bucket.spec.name}` crée une dépendance. kro crée un graphe acyclique dirigé (DAG) de toutes les ressources et de leurs dépendances, puis calcule un ordre topologique pour la création.
**Ordre de création** : les ressources sont créées dans l'ordre topologique (les dépendances d'abord).
**Création parallèle** : les ressources sans dépendances sont créées simultanément.
**Ordre de suppression** : les ressources sont supprimées dans l'ordre topologique inverse (les personnes dépendantes d'abord).
**Dépendances circulaires** : non autorisées : kro rejette les dépendances circulaires lors de la ResourceGraphDefinitions validation.
Vous pouvez consulter l'ordre de création calculé :
```
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.topologicalOrder}'
```
Pour plus d'informations, consultez la section [Inférence graphique](https://kro.run/docs/concepts/rgd/dependencies-ordering/) dans la documentation de kro.
## Composer avec ACK
kro fonctionne parfaitement avec la capacité EKS permettant à ACK de composer des AWS ressources avec des ressources Kubernetes :
```
resources:
# Create {aws} S3 bucket with ACK
- id: bucket
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
spec:
name: ${schema.spec.name}-files
# Inject bucket details into Kubernetes ConfigMap
- id: config
template:
apiVersion: v1
kind: ConfigMap
data:
BUCKET_NAME: ${bucket.spec.name}
BUCKET_ARN: ${bucket.status.ackResourceMetadata.arn}
# Use ConfigMap in application deployment
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- name: app
envFrom:
- configMapRef:
name: ${config.metadata.name}
```
Ce modèle vous permet de créer des AWS ressources, d'extraire leurs détails (ARNs, URLs, points de terminaison) et de les injecter dans la configuration de votre application, le tout géré comme une seule unité.
Pour plus de modèles de composition et des exemples avancés, voir[considérations relatives à Kro pour EKS](kro-considerations.md).
## Étapes suivantes
+ [considérations relatives à Kro pour EKS](kro-considerations.md)- Découvrez les modèles spécifiques à EKS, le RBAC et l'intégration avec ACK et Argo CD
+ Documentation [kro - Documentation](https://kro.run/docs/overview) kro complète, y compris les expressions CEL avancées, les modèles de validation et le dépannage
# Configurer les autorisations Kro
Contrairement à ACK et Argo CD, kro ne nécessite pas d'autorisations IAM. kro fonctionne entièrement au sein de votre cluster Kubernetes et n'effectue pas d'appels d'API. AWS Contrôlez l'accès aux ressources Kro à l'aide de la norme Kubernetes RBAC.
## Comment fonctionnent les autorisations avec Kro
kro utilise deux types de ressources Kubernetes avec des portées différentes :
**ResourceGraphDefinitions**: ressources étendues au cluster qui définissent la personnalisation. APIs Généralement géré par les équipes de plateforme qui conçoivent et maintiennent les normes organisationnelles.
**Instances** : ressources personnalisées étendues à l'espace de noms créées à partir de. ResourceGraphDefinitions Peut être créé par les équipes chargées des applications disposant des autorisations RBAC appropriées.
Par défaut, la fonctionnalité Kro dispose des autorisations nécessaires pour gérer ResourceGraphDefinitions ses instances via la politique de saisie d'`AmazonEKSKROPolicy`accès. Cependant, kro a besoin d'autorisations supplémentaires pour créer et gérer les ressources Kubernetes sous-jacentes définies dans votre répertoire ResourceGraphDefinitions (telles que les déploiements, les services ou les ressources ACK). Vous devez accorder ces autorisations par le biais de politiques d'entrée d'accès ou de Kubernetes RBAC. Pour plus de détails sur l'octroi de ces autorisations, voir [Autorisations de ressources arbitraires kro](capabilities-security.md#kro-resource-permissions).
## Autorisations de l'équipe de plateforme
Les équipes de la plateforme ont besoin d'autorisations pour créer et gérer ResourceGraphDefinitions.
**Exemple ClusterRole pour les équipes de plateforme** :
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kro-platform-admin
rules:
- apiGroups: ["kro.run"]
resources: ["resourcegraphdefinitions"]
verbs: ["*"]
```
**Associez les membres de l'équipe de la plateforme** :
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: platform-team-kro-admin
subjects:
- kind: Group
name: platform-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kro-platform-admin
apiGroup: rbac.authorization.k8s.io
```
## Autorisations de l'équipe d'application
Les équipes d'application ont besoin d'autorisations pour créer des instances de ressources personnalisées dans leurs espaces de noms.
**Exemple de rôle pour les équipes de candidature** :
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: kro-app-developer
namespace: my-app
rules:
- apiGroups: ["kro.run"]
resources: ["webapps", "databases"]
verbs: ["create", "get", "list", "update", "delete", "patch"]
```
**Associez les membres de l'équipe de candidature** :
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-team-kro-developer
namespace: my-app
subjects:
- kind: Group
name: app-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: kro-app-developer
apiGroup: rbac.authorization.k8s.io
```
**Note**
Le groupe d'API du rôle (`kro.run`dans cet exemple) doit correspondre à celui `apiVersion` défini dans votre ResourceGraphDefinition schéma.
## Accès en lecture seule
Accordez un accès en lecture seule à la vue ResourceGraphDefinitions et aux instances sans autorisation de modification.
**Lecture seule ClusterRole** :
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kro-viewer
rules:
- apiGroups: ["kro.run"]
resources: ["resourcegraphdefinitions"]
verbs: ["get", "list", "watch"]
```
**Rôle en lecture seule pour les instances** :
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: kro-instance-viewer
namespace: my-app
rules:
- apiGroups: ["kro.run"]
resources: ["webapps", "databases"]
verbs: ["get", "list", "watch"]
```
## Accès à plusieurs espaces de noms
Accordez aux équipes d'application l'accès à plusieurs espaces de noms à l'aide de ClusterRoles with RoleBindings.
**ClusterRole pour l'accès à plusieurs espaces de noms :**
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kro-multi-namespace-developer
rules:
- apiGroups: ["kro.run"]
resources: ["webapps"]
verbs: ["create", "get", "list", "update", "delete"]
```
**Liez à des espaces de noms spécifiques :**
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-team-dev-access
namespace: development
subjects:
- kind: Group
name: app-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kro-multi-namespace-developer
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-team-staging-access
namespace: staging
subjects:
- kind: Group
name: app-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kro-multi-namespace-developer
apiGroup: rbac.authorization.k8s.io
```
## Bonnes pratiques
**Principe du moindre privilège** : accordez uniquement les autorisations minimales nécessaires pour les responsabilités de chaque équipe.
**Utilisez des groupes plutôt que des utilisateurs individuels** : liez les rôles à des groupes plutôt qu'à des utilisateurs individuels pour faciliter la gestion.
**Problèmes liés à la plateforme et à l'application distincts** : les équipes chargées de la plateforme gèrent ResourceGraphDefinitions, les équipes chargées des applications gèrent les instances.
**Isolation des espaces de noms** : utilisez des espaces de noms pour isoler différentes équipes ou environnements, le RBAC contrôlant l'accès à chaque espace de noms.
Accès **en lecture seule pour l'audit : fournissez un accès** en lecture seule aux équipes de sécurité et de conformité à des fins d'audit.
## Étapes suivantes
+ [concepts kro](kro-concepts.md)- Comprendre les concepts Kro et la composition des ressources
+ [concepts kro](kro-concepts.md)- Comprendre SimpleSchema les expressions CEL et les modèles de composition
+ [Considérations relatives à la sécurité relatives aux fonctionnalités EKS](capabilities-security.md)- Passez en revue les meilleures pratiques de sécurité en termes de fonctionnalités
# 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, voir[Configurer les autorisations Kro](kro-permissions.md).
### 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 \$1 file d'attente SQS \$1 configuration des notifications
+ **Pile de base** de données : instance RDS \$1 groupe de paramètres \$1 groupe de sécurité \$1 secret Secrets Manager
+ **Mise en réseau** : VPC \$1 sous-réseaux \$1 tables de routage \$1 groupes de sécurité \$1 passerelles NAT
+ **Calcul avec stockage** : EC2 instance \$1 volumes EBS \$1 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, voir[Concepts d'ACK](ack-concepts.md).
### 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, voir[Travailler avec Argo CD](working-with-argocd.md).
## 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 :
+ [Débuter avec kro](https://kro.run/docs/guides/getting-started) - Création ResourceGraphDefinitions
+ [Expressions CEL](https://kro.run/docs/concepts/cel) - Écrire des expressions CEL
+ [Kro Guides](https://kro.run/docs/guides/) - Modèles de composition avancés
+ [Dépannage](https://kro.run/docs/troubleshooting) - Dépannage et débogage
## Étapes suivantes
+ [Configurer les autorisations Kro](kro-permissions.md)- Configurer le RBAC pour les équipes chargées des plateformes et des applications
+ [concepts kro](kro-concepts.md)- Comprendre les concepts Kro et le cycle de vie des ressources
+ [Résoudre les problèmes liés aux fonctionnalités Kro](kro-troubleshooting.md)- Résoudre les problèmes liés à KRO
+ [Concepts d'ACK](ack-concepts.md)- En savoir plus sur les ressources d'ACK pour la composition
+ [Travailler avec Argo CD](working-with-argocd.md)- Déploiement RGDs et instances avec GitOps
# Résoudre les problèmes liés aux fonctionnalités Kro
Cette rubrique fournit des conseils de dépannage relatifs à la fonctionnalité EKS pour kro, notamment les vérifications de l'état des fonctionnalités, les autorisations RBAC, les erreurs d'expression CEL et les problèmes de composition des ressources.
**Note**
Les fonctionnalités EKS sont entièrement gérées et exécutées en dehors de votre cluster. Vous n'avez pas accès aux journaux du contrôleur ni à l'espace de `kro-system` noms. Le dépannage se concentre sur l'état des capacités, la configuration RBAC et l'état des ressources.
## La fonctionnalité est ACTIVE mais ResourceGraphDefinitions ne fonctionne pas
Si votre capacité Kro affiche un `ACTIVE` état mais ResourceGraphDefinitions ne crée pas de ressources sous-jacentes, vérifiez l'état de la fonctionnalité, les autorisations RBAC et l'état des ressources.
**Vérifiez l'état de santé des capacités** :
Vous pouvez consulter les problèmes liés à l'état et à l'état des fonctionnalités dans la console EKS ou à l'aide de la AWS CLI.
**Console** :
1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/ home\$1/clusters.
1. Sélectionnez le nom de votre cluster.
1. Sélectionnez l’onglet **Observabilité**.
1. Sélectionnez **Surveiller le cluster**.
1. Choisissez l'onglet **Fonctionnalités** pour afficher l'état et l'état de toutes les fonctionnalités.
** AWS CLI** :
```
# View capability status and health
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro
# Look for issues in the health section
```
**Causes courantes :**
+ **Permissions RBAC manquantes** : kro n'a pas les autorisations nécessaires pour créer des ressources Kubernetes sous-jacentes
+ **Expressions CEL non valides** : erreurs de syntaxe dans ResourceGraphDefinition
+ **Dépendances des ressources : les** ressources dépendantes ne sont pas prêtes
+ **Validation du schéma** : l'instance ne répond pas aux exigences du schéma RGD
**Vérifiez les autorisations RBAC** :
```
# Check if capability has cluster admin policy
kubectl get accessentry -A | grep kro
```
Si la fonctionnalité ne dispose pas des autorisations requises, associez-la à l'`AmazonEKSClusterAdminPolicy`entrée d'accès de la fonctionnalité kro ou créez des politiques RBAC plus restrictives pour une utilisation en production. Consultez [Configurer les autorisations Kro](kro-permissions.md) pour plus de détails.
**Vérifier ResourceGraphDefinition le statut** :
```
# List all RGDs
kubectl get resourcegraphdefinition
# Describe specific RGD
kubectl describe resourcegraphdefinition my-rgd
# Check for validation errors
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.conditions}'
```
ResourceGraphDefinitions ont trois conditions de statut clés :
+ `ResourceGraphAccepted`- Si le RGD a réussi la validation (syntaxe CEL, vérification de type, existence du champ)
+ `KindReady`- Si le CRD de votre API personnalisée a été généré et enregistré
+ `ControllerReady`- Si kro surveille activement les instances de votre API personnalisée
Si tel `ResourceGraphAccepted` est le cas`False`, vérifiez que le message de condition ne contient pas d'erreurs de validation, telles que des champs inconnus, des incohérences de type ou des dépendances circulaires.
## Instances créées mais les ressources sous-jacentes n'apparaissent pas
Si des instances de ressources personnalisées existent mais que les ressources Kubernetes sous-jacentes (déploiements, services ConfigMaps) ne sont pas créées, vérifiez que kro dispose des autorisations nécessaires et vérifiez qu'il n'y a pas d'erreurs de composition.
**Vérifiez l'état de l'instance** :
```
# Describe the instance (replace with your custom resource kind and name)
kubectl describe custom-kind
my-instance
# View instance events
kubectl get events --field-selector involvedObject.name=my-instance
# Check instance status conditions
kubectl get custom-kind
my-instance -o jsonpath='{.status.conditions}'
# Check instance state
kubectl get custom-kind
my-instance -o jsonpath='{.status.state}'
```
Les instances possèdent un `state` champ indiquant un statut élevé :
+ `ACTIVE`- L'instance est en cours d'exécution avec succès
+ `IN_PROGRESS`- L'instance est en cours de traitement ou de réconciliation
+ `FAILED`- L'instance n'a pas pu être réconciliée
+ `DELETING`- L'instance est en cours de suppression
+ `ERROR`- Une erreur s'est produite lors du traitement
Les instances sont également soumises à quatre conditions de statut :
+ `InstanceManaged`- Les finaliseurs et les étiquettes sont correctement définis
+ `GraphResolved`- Graphe d'exécution créé et ressources résolues
+ `ResourcesReady`- Toutes les ressources créées et prêtes
+ `Ready`- Santé globale de l'instance (elle ne l'est que `True` lorsque toutes les sous-conditions le sont`True`)
Concentrez-vous sur la `Ready` condition pour déterminer l'état de santé de l'instance. Si tel `Ready` est le cas`False`, vérifiez les sous-conditions pour identifier la phase qui a échoué.
**Vérifiez les autorisations RBAC** :
La fonctionnalité Kro nécessite des autorisations pour créer les ressources Kubernetes sous-jacentes définies dans votre. ResourceGraphDefinitions
```
# Check if the capability has the AmazonEKSClusterAdminPolicy
kubectl get accessentry -A | grep kro
```
Si des autorisations sont manquantes, `AmazonEKSClusterAdminPolicy` associez-les à l'entrée d'accès de la fonctionnalité kro ou créez des politiques RBAC plus restrictives pour une utilisation en production. Consultez [Configurer les autorisations Kro](kro-permissions.md) pour plus de détails.
## Erreurs d'expression CEL
Les erreurs d'expression CEL sont détectées au moment de ResourceGraphDefinition la création, et non lors de la création des instances. kro valide toute la syntaxe des CEL, vérifie le type des expressions par rapport aux schémas Kubernetes et vérifie l'existence des champs lorsque vous créez le RGD.
**Erreurs de validation CEL courantes** :
+ Référence de **champ non définie : référence** à un champ qui n'existe pas dans le schéma ou dans la ressource
+ **Incompatibilité de type** : l'expression renvoie un type incorrect (par exemple, une chaîne où un entier est attendu)
+ **Syntaxe non valide** : crochets, guillemets ou opérateurs manquants dans l'expression CEL
+ **Type de ressource inconnu** : Référencement d'un CRD qui n'existe pas dans le cluster
**Vérifiez l'état de validation du RGD** :
```
# Check if RGD was accepted
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.conditions[?(@.type=="ResourceGraphAccepted")]}'
# View detailed validation errors
kubectl describe resourcegraphdefinition my-rgd
```
Si tel `ResourceGraphAccepted` est le cas`False`, le message de condition contient l'erreur de validation.
**Exemples d'expressions CEL valides** :
```
# Reference schema field
${schema.spec.appName}
# Conditional expression
${schema.spec.replicas > 1}
# String template (expressions must return strings)
name: "${schema.spec.appName}-service"
# Standalone expression (can be any type)
replicas: ${schema.spec.replicaCount}
# Resource reference
${deployment.status.availableReplicas}
# Optional field access (returns null if field doesn't exist)
${configmap.data.?DATABASE_URL}
```
## Les dépendances des ressources ne sont pas résolues
kro déduit automatiquement les dépendances à partir des expressions CEL et crée les ressources dans le bon ordre. Si les ressources ne sont pas créées comme prévu, vérifiez l'ordre des dépendances et l'état de préparation des ressources.
**Afficher l'ordre de création calculé** :
```
# See the order kro will create resources
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.topologicalOrder}'
```
Cela montre l'ordre calculé en fonction des références d'expression CEL entre les ressources.
**Vérifiez l'état de préparation des ressources** :
```
# View instance status to see which resources are ready
kubectl get custom-kind
my-instance -o jsonpath='{.status}'
# Check specific resource status
kubectl get deployment my-deployment -o jsonpath='{.status.conditions}'
```
**Vérifiez les conditions ReadyWhen (si elles sont utilisées)** :
Le champ `readyWhen` est facultatif. Si elles ne sont pas spécifiées, les ressources sont considérées comme prêtes immédiatement après leur création. Si vous avez défini `readyWhen` des conditions, vérifiez qu'elles vérifient correctement l'état de préparation des ressources :
```
resources:
- id: deployment
readyWhen:
- ${deployment.status.availableReplicas == deployment.spec.replicas}
```
**Vérifiez les événements liés aux ressources** :
```
# View events for the underlying resources
kubectl get events -n namespace --sort-by='.lastTimestamp'
```
## Défaillances de validation du schéma
Si les instances ne sont pas créées en raison d'erreurs de validation du schéma, vérifiez que l'instance répond aux exigences du schéma RGD.
**Vérifiez les erreurs de validation** :
```
# Attempt to create instance and view error
kubectl apply -f instance.yaml
# View existing instance validation status
kubectl describe custom-kind
my-instance | grep -A 5 "Validation"
```
**Problèmes de validation courants** :
+ **Champs obligatoires manquants** : l'instance ne fournit pas tous les champs de schéma obligatoires
+ **Incompatibilité de type** : fourniture d'une chaîne où un entier est attendu
+ **Valeur d'énumération non valide** : utilisation d'une valeur ne figurant pas dans la liste autorisée
+ **Incompatibilité du modèle** : la chaîne ne correspond pas au modèle regex
Passez en **revue le schéma RGD** :
```
# View the schema definition
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.spec.schema}'
```
Assurez-vous que votre instance fournit tous les champs obligatoires avec les types corrects.
## Étapes suivantes
+ [considérations relatives à Kro pour EKS](kro-considerations.md)- considérations clés et meilleures pratiques
+ [Configurer les autorisations Kro](kro-permissions.md)- Configurer le RBAC pour les équipes chargées des plateformes et des applications
+ [concepts kro](kro-concepts.md)- Comprendre les concepts Kro et le cycle de vie des ressources
+ [Dépannage des fonctionnalités EKS](capabilities-troubleshooting.md)- Conseils généraux de résolution des problèmes liés aux fonctionnalités
# Comparaison entre la capacité EKS pour kro et celle pour kro autogérée
L'EKS Capability for kro fournit les mêmes fonctionnalités que le kro autogéré, mais avec des avantages opérationnels significatifs. Pour une comparaison générale des fonctionnalités EKS par rapport aux solutions autogérées, voir[Considérations relatives aux fonctionnalités EKS](capabilities-considerations.md).
La capacité EKS pour kro utilise les mêmes contrôleurs kro en amont et est entièrement compatible avec le kro en amont. ResourceGraphDefinitions, les expressions CEL et la composition des ressources fonctionnent de manière identique. Pour une documentation complète et des exemples de kro, consultez la documentation de [kro](https://kro.run/docs/overview).
## Voie de migration
Vous pouvez passer d'une solution kro autogérée à une fonctionnalité gérée sans aucune interruption de service.
**Important**
Avant de migrer, assurez-vous que votre contrôleur kro autogéré exécute la même version que la capacité EKS pour kro. Vérifiez la version des fonctionnalités dans la console EKS ou à l'aide de `aws eks describe-capability` celle-ci, puis mettez à niveau votre installation autogérée en conséquence. Cela permet d'éviter les problèmes de compatibilité lors de la migration.
1. Mettez à jour votre contrôleur Kro autogéré pour l'utiliser `kube-system` pour les baux électoraux des dirigeants :
```
helm upgrade --install kro \
oci://ghcr.io/awslabs/kro/kro-chart \
--namespace kro \
--set leaderElection.namespace=kube-system
```
Cela déplace le bail du contrôleur vers`kube-system`, ce qui permet à la capacité gérée de se coordonner avec celui-ci.
1. Créez la fonctionnalité Kro sur votre cluster (voir[Création d'une fonctionnalité Kro](create-kro-capability.md))
1. La fonctionnalité gérée reconnaît les instances existantes ResourceGraphDefinitions et prend en charge la réconciliation
1. Diminuez ou supprimez progressivement les déploiements KRO autogérés :
```
helm uninstall kro --namespace kro
```
Cette approche permet aux deux contrôleurs de coexister en toute sécurité pendant la migration. La fonctionnalité gérée adopte automatiquement ResourceGraphDefinitions les instances précédemment gérées par Kro autogéré, garantissant ainsi un rapprochement continu sans conflits.
## Étapes suivantes
+ [Création d'une fonctionnalité Kro](create-kro-capability.md)- Création d'une ressource de capacité Kro
+ [concepts kro](kro-concepts.md)- Comprendre les concepts Kro et la composition des ressources