**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
<a name="kro-concepts"></a>

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
<a name="_getting_started_with_kro"></a>

Nachdem Sie die Kro-Fähigkeit erstellt haben (siehe[Eine Kro-Fähigkeit erstellen](create-kro-capability.md)), 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
<a name="_core_concepts"></a>

**Wichtig**  
kro validiert zur Zeit ResourceGraphDefinitions der Erstellung, nicht zur Laufzeit. Wenn Sie eine RGD erstellen, validiert Kro die CEL-Syntax, überprüft Ausdrücke anhand der tatsächlichen Kubernetes-Schemas, verifiziert das Vorhandensein von Feldern und erkennt zirkuläre Abhängigkeiten. Das bedeutet, dass Fehler sofort bei der Erstellung der RGD erkannt werden, bevor Instanzen bereitgestellt werden.

### ResourceGraphDefinition
<a name="_resourcegraphdefinition"></a>

A ResourceGraphDefinition (RGD) definiert eine benutzerdefinierte Kubernetes-API durch Angabe von:
+  **Schema** — Die API-Struktur unter Verwendung des SimpleSchema Formats (Feldnamen, Typen, Standardwerte, Validierung)
+  **Ressourcen** — Vorlagen für das zugrunde liegende Kubernetes oder AWS zu erstellende Ressourcen
+  **Abhängigkeiten** — Wie Ressourcen zueinander in Beziehung stehen (wird automatisch anhand von Feldreferenzen erkannt)

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](https://kro.run/docs/concepts/rgd/overview/).

### SimpleSchema formatieren
<a name="_simpleschema_format"></a>

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ützt`string`, `integer``boolean`, und `number` Typen mit Einschränkungen wie`required`,`default`,`minimum`/`maximum``enum`, und. `pattern`

Weitere Informationen finden Sie [SimpleSchema](https://kro.run/docs/concepts/rgd/schema/)in der KRO-Dokumentation.

### CEL-Ausdrücke
<a name="_cel_expressions"></a>

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 verwendet`string()`, um andere Typen zu konvertieren:`"replicas-${string(schema.spec.count)}"`.

 **Feldverweise** — Greifen Sie auf Instanzspezifikationswerte zu, indem Sie`schema.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](https://kro.run/docs/concepts/rgd/cel-expressions/).

### Abhängigkeiten von Ressourcen
<a name="_resource_dependencies"></a>

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](https://kro.run/docs/concepts/rgd/dependencies-ordering/) in der KRO-Dokumentation.

## Komponieren mit ACK
<a name="_composing_with_ack"></a>

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](kro-considerations.md)

## Nächste Schritte
<a name="_next_steps"></a>
+  [Überlegungen zu Kro für EKS](kro-considerations.md)- Erfahren Sie mehr über EKS-spezifische Muster, RBAC und die Integration mit ACK und Argo CD
+  [kro-Dokumentation — Umfassende Kro-Dokumentation](https://kro.run/docs/overview) mit erweiterten CEL-Ausdrücken, Validierungsmustern und Problemlösungen