Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Kro-Konzepte

kro ermöglicht es Plattformteams, benutzerdefinierte Kubernetes zu erstellen, die mehrere Ressourcen zu Abstraktionen auf APIs höherer Ebene zusammensetzen. In diesem Thema wird ein praktisches Beispiel vorgestellt und anschließend die Kernkonzepte erklärt, die Sie verstehen müssen, wenn Sie mit der EKS-Funktion für kro arbeiten.

Erste Schritte mit Kro

Nachdem Sie die Kro-Fähigkeit erstellt haben (sieheEine Kro-Fähigkeit erstellen), können Sie APIs mit der Erstellung benutzerdefinierter Anwendungen ResourceGraphDefinitions in Ihrem Cluster beginnen.

Hier ist ein vollständiges Beispiel, das eine einfache Abstraktion einer Webanwendung erstellt:

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

Nach der Anwendung ResourceGraphDefinition können Anwendungsteams Webanwendungen mithilfe Ihrer vereinfachten API erstellen:

apiVersion: kro.run/v1alpha1
kind: WebApplication
metadata:
  name: my-app
spec:
  name: my-app
  replicas: 5

kro erstellt das Deployment und den Service automatisch mit der entsprechenden Konfiguration. Da image nicht angegeben ist, wird der Standardwert nginx:latest aus dem Schema verwendet.

Schlüsselkonzepte

ResourceGraphDefinition

A ResourceGraphDefinition (RGD) definiert eine benutzerdefinierte Kubernetes-API durch Angabe von:

Wenn Sie eine RGD anwenden, registriert Kro eine neue benutzerdefinierte Ressourcendefinition (CRD) in Ihrem Cluster. Anwendungsteams können dann Instanzen Ihrer benutzerdefinierten API erstellen, und kro kümmert sich um die Erstellung und Verwaltung aller zugrunde liegenden Ressourcen.

Weitere Informationen finden Sie in der Kro-Dokumentation unter ResourceGraphDefinition Überblick.

SimpleSchema formatieren

SimpleSchema bietet eine vereinfachte Möglichkeit, API-Schemas zu definieren, ohne dass OpenAPI-Kenntnisse erforderlich sind:

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 unterstütztstring, integerboolean, und number Typen mit Einschränkungen wierequired,default,minimum/maximumenum, und. pattern

Weitere Informationen finden Sie SimpleSchemain der KRO-Dokumentation.

CEL-Ausdrücke

kro verwendet Common Expression Language (CEL), um Werte dynamisch zu referenzieren und bedingte Logik hinzuzufügen. CEL-Ausdrücke sind in ${ und eingeschlossen } und können auf zwei Arten verwendet werden:

Eigenständige Ausdrücke — Der gesamte Feldwert ist ein einziger Ausdruck:

spec:
  replicas: ${schema.spec.replicaCount}  # Expression returns integer
  labels: ${schema.spec.labelMap}        # Expression returns object

Das Ausdrucksergebnis ersetzt den gesamten Feldwert und muss dem erwarteten Feldtyp entsprechen.

Zeichenkettenvorlagen — Ein oder mehrere Ausdrücke, die in eine Zeichenfolge eingebettet sind:

metadata:
  name: "${schema.spec.prefix}-${schema.spec.name}"  # Multiple expressions
  annotation: "Created by ${schema.spec.owner}"      # Single expression in string

Alle Ausdrücke in Zeichenkettenvorlagen müssen Zeichenketten zurückgeben. Wird verwendetstring(), um andere Typen zu konvertieren:"replicas-${string(schema.spec.count)}".

Feldverweise — Greifen Sie auf Instanzspezifikationswerte zu, indem Sieschema.spec:

template:
  metadata:
    name: ${schema.spec.name}-deployment
    namespace: ${schema.metadata.namespace}  # Can also reference metadata
  spec:
    replicas: ${schema.spec.replicas}

Optionaler Feldzugriff — Wird ? für Felder verwendet, die möglicherweise nicht existieren:

# For ConfigMaps or Secrets with unknown structure
value: ${configmap.data.?DATABASE_URL}

# For optional status fields
ready: ${deployment.status.?readyReplicas > 0}

Wenn das Feld nicht existiert, wird der Ausdruck zurückgegeben null und schlägt nicht fehl.

Bedingte Ressourcen — Beziehen Sie Ressourcen nur ein, wenn die Bedingungen erfüllt sind:

resources:
- id: ingress
  includeWhen:
    - ${schema.spec.enableIngress == true}
  template:
    # ... ingress configuration

Das includeWhen Feld akzeptiert eine Liste von booleschen Ausdrücken. Alle Bedingungen müssen erfüllt sein, damit die Ressource erstellt werden kann. Derzeit includeWhen können nur schema.spec Felder referenziert werden.

Transformationen — Transformieren Sie Werte mit ternären Operatoren und Funktionen:

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)}

Ressourcenübergreifende Referenzen — Referenzwerte aus anderen Ressourcen:

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}

Wenn Sie in einem CEL-Ausdruck auf eine andere Ressource verweisen, wird automatisch eine Abhängigkeit erstellt. kro stellt sicher, dass die referenzierte Ressource zuerst erstellt wird.

Weitere Informationen finden Sie in der KRO-Dokumentation unter CEL-Ausdrücke.

Abhängigkeiten von Ressourcen

kro leitet Abhängigkeiten automatisch aus CEL-Ausdrücken ab — Sie geben die Reihenfolge nicht an, sondern beschreiben Beziehungen. Wenn eine Ressource mithilfe eines CEL-Ausdrucks auf eine andere Ressource verweist, erstellt Kro eine Abhängigkeit und bestimmt die richtige Erstellungsreihenfolge.

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

Der Ausdruck ${bucket.spec.name} erzeugt eine Abhängigkeit. kro erstellt einen gerichteten azyklischen Graphen (DAG) aller Ressourcen und ihrer Abhängigkeiten und berechnet dann eine topologische Reihenfolge für die Erstellung.

Erstellungsreihenfolge: Ressourcen werden in topologischer Reihenfolge erstellt (Abhängigkeiten zuerst).

Parallele Erstellung: Ressourcen ohne Abhängigkeiten werden gleichzeitig erstellt.

Löschreihenfolge: Ressourcen werden in umgekehrter topologischer Reihenfolge gelöscht (abhängige Objekte zuerst).

Zirkuläre Abhängigkeiten: Nicht zulässig — kro lehnt ResourceGraphDefinitions bei der Validierung zirkuläre Abhängigkeiten ab.

Sie können die berechnete Erstellungsreihenfolge einsehen:

kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.topologicalOrder}'

Weitere Informationen finden Sie unter Graph-Inferenz in der KRO-Dokumentation.

Komponieren mit ACK

kro arbeitet nahtlos mit der EKS-Funktion für ACK zusammen, um AWS Ressourcen mit Kubernetes-Ressourcen zusammenzustellen:

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}

Mit diesem Muster können Sie AWS Ressourcen erstellen, ihre Details (ARNs, URLs, Endpunkte) extrahieren und sie in Ihre Anwendungskonfiguration einfügen — alles wird als eine Einheit verwaltet.

Weitere Kompositionsmuster und Beispiele für Fortgeschrittene finden Sie unter. Überlegungen zu Kro für EKS

Nächste Schritte