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.

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 (voirCréation d'une fonctionnalité Kro), 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

ResourceGraphDefinition

A ResourceGraphDefinition (RGD) définit une API Kubernetes personnalisée en spécifiant :

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 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 integerboolean,, et number types avec des contraintes telles que requireddefault,maximum,minimum/enum, etpattern.

Pour plus d'informations, consultez SimpleSchemala 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 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 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, voirconsidérations relatives à Kro pour EKS.

Étapes suivantes