

 **Contribuisci a migliorare questa pagina** 

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Composizione delle risorse con kro (Kube Resource Orchestrator)
<a name="kro"></a>

 **kro (Kube Resource Orchestrator) è un progetto open source nativo di Kubernetes che consente di definire Kubernetes** personalizzati utilizzando una configurazione semplice e diretta. APIs Con kro, puoi configurare facilmente nuove funzionalità personalizzate che creano un gruppo di oggetti Kubernetes e le operazioni logiche tra di essi. APIs 

Con EKS Capabilities, kro è completamente gestito da AWS, eliminando la necessità di installare, mantenere e scalare i controller kro sui cluster.

## Come funziona kro
<a name="_how_kro_works"></a>

kro introduce una Custom Resource Definition (CRD) chiamata `ResourceGraphDefinition` (RGD) che consente la creazione semplice e semplificata di Kubernetes personalizzati. APIs Quando crei un file`ResourceGraphDefinition`, kro utilizza estensioni Kubernetes native per crearne e gestirne di nuove nel tuo cluster. APIs A partire da questa specifica di singola risorsa, kro creerà e registrerà per te un nuovo CRD in base alle tue specifiche e si adatterà per gestire le tue risorse personalizzate appena definite.

RGDs può includere più risorse e kro determinerà le interdipendenze e l'ordine delle risorse, quindi non è necessario. È possibile utilizzare una sintassi semplice per inserire la configurazione da una risorsa all'altra, semplificando notevolmente le composizioni ed eliminando la necessità di operatori «collanti» nel cluster. Con kro, le tue risorse personalizzate possono includere risorse Kubernetes native e qualsiasi definizione di risorsa personalizzata () installata nel cluster. CRDs

kro supporta un singolo tipo di risorsa principale:
+  **ResourceGraphDefinition (RGD)**: definisce una risorsa personalizzata Kubernetes, incapsulando una o più risorse Kubernetes native o personalizzate sottostanti

Oltre a questa risorsa, kro creerà e gestirà il ciclo di vita delle risorse personalizzate create con essa, nonché tutte le risorse che le costituiscono.

kro si integra perfettamente con AWS Controllers for Kubernetes (ACK), consentendoti di comporre risorse per il carico di lavoro con risorse per creare astrazioni di livello superiore. AWS Ciò consente di creare i propri elementi costitutivi del cloud, semplificando la gestione delle risorse e abilitando modelli riutilizzabili con impostazioni di configurazione predefinite e immutabili basate sugli standard organizzativi.

## Vantaggi di kro
<a name="_benefits_of_kro"></a>

kro consente ai team della piattaforma di creare Kubernetes personalizzati APIs che compongono più risorse in astrazioni di livello superiore. Ciò semplifica la gestione delle risorse consentendo agli sviluppatori di implementare applicazioni complesse utilizzando risorse personalizzate semplici, standardizzate e con versioni diverse. Definisci modelli riutilizzabili per combinazioni di risorse comuni, consentendo una creazione coerente di risorse in tutta l'organizzazione.

kro utilizza il [Common Expression Language (CEL) in Kubernetes](https://kubernetes.io/docs/reference/using-api/cel/) per trasferire valori tra le risorse e incorporare la logica condizionale, offrendo flessibilità nella composizione delle risorse. Puoi comporre sia le risorse Kubernetes che le AWS risorse gestite da ACK in modo unificato e personalizzato, abilitando definizioni complete di applicazioni e infrastrutture. APIs

kro supporta la configurazione dichiarativa tramite i manifesti di Kubernetes, abilitando i GitOps flussi di lavoro e l'infrastruttura come pratiche di codice che si integrano perfettamente con i processi di sviluppo esistenti. Come parte di EKS Managed Capabilities, kro è completamente gestito da AWS, eliminando la necessità di installare, configurare e mantenere i controller kro sui cluster.

 **Esempio: creazione di un ResourceGraphDefinition** 

L'esempio seguente mostra una procedura semplice `ResourceGraphDefinition` che crea un'applicazione Web con una distribuzione e un servizio:

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

Quando gli utenti creano istanze della risorsa `WebApplication` personalizzata, kro crea automaticamente le risorse di distribuzione e servizio corrispondenti, gestendone il ciclo di vita insieme alla risorsa personalizzata.

## Integrazione con altre funzionalità gestite da EKS
<a name="_integration_with_other_eks_managed_capabilities"></a>

kro si integra con altre funzionalità gestite da EKS.
+  ** AWS Controllers for Kubernetes (ACK): usa kro per comporre le risorse ACK** in astrazioni di livello superiore, semplificando la gestione delle risorse. AWS 
+  **Argo CD: utilizza Argo CD** per gestire l'implementazione di risorse personalizzate kro su più cluster, abilitando flussi di lavoro per gli elementi costitutivi della piattaforma e gli stack di applicazioni. GitOps 

## Guida introduttiva a kro
<a name="_getting_started_with_kro"></a>

Per iniziare a usare EKS Capability for kro:

1.  [Crea una risorsa con funzionalità kro](create-kro-capability.md) sul tuo cluster EKS tramite la AWS console, la AWS CLI o la tua infrastruttura preferita come strumento di codice.

1. Crea ResourceGraphDefinitions (RGDs) che definisce le tue composizioni personalizzate APIs e di risorse.

1. Applica istanze delle tue risorse personalizzate per fornire e gestire Kubernetes e risorse sottostanti. AWS 

# Crea una funzionalità kro
<a name="create-kro-capability"></a>

Questo argomento spiega come creare una funzionalità kro sul tuo cluster Amazon EKS.

## Prerequisiti
<a name="_prerequisites"></a>

Prima di creare una funzionalità kro, assicurati di avere:
+ Un cluster Amazon EKS esistente che esegue una versione di Kubernetes supportata (sono supportate tutte le versioni con supporto standard ed esteso)
+ Autorizzazioni IAM sufficienti per creare risorse di funzionalità sui cluster EKS
+ (Per CLI/EksCtl) Lo strumento CLI appropriato installato e configurato

**Nota**  
A differenza di ACK e Argo CD, kro non richiede autorizzazioni IAM aggiuntive oltre alla policy di fiducia. kro opera interamente all'interno del cluster e non effettua chiamate API. AWS Tuttavia, è comunque necessario fornire a un IAM Capability Role la policy di fiducia appropriata. Per informazioni sulla configurazione delle autorizzazioni RBAC di Kubernetes per kro, consulta. [Configura le autorizzazioni kro](kro-permissions.md)

## Scegli il tuo strumento
<a name="_choose_your_tool"></a>

Puoi creare una funzionalità kro usando Console di gestione AWS, AWS CLI o eksctl:
+  [Crea una funzionalità kro utilizzando la console](kro-create-console.md)- Usa la console per un'esperienza guidata
+  [Crea una funzionalità kro utilizzando la CLI AWS](kro-create-cli.md)- Usa la AWS CLI per lo scripting e l'automazione
+  [Crea una funzionalità kro usando eksctl](kro-create-eksctl.md)- Usa eksctl per un'esperienza nativa di Kubernetes

## Cosa succede quando crei una funzionalità kro
<a name="_what_happens_when_you_create_a_kro_capability"></a>

Quando crei una funzionalità kro:

1. EKS crea il servizio di capacità kro e lo configura per monitorare e gestire le risorse nel cluster

1. Le definizioni di risorse personalizzate (CRDs) sono installate nel cluster

1. Viene creata automaticamente una voce di accesso per il tuo IAM Capability Role `AmazonEKSKROPolicy` che concede le autorizzazioni per la gestione ResourceGraphDefinitions e le relative istanze (vedi) [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)

1. La funzionalità presuppone l'IAM Capability Role fornito dall'utente (utilizzato solo per la relazione di fiducia)

1. kro inizia a controllare `ResourceGraphDefinition` le risorse e le relative istanze

1. Lo stato della capacità cambia da a `CREATING` `ACTIVE` 

Una volta attivo, è possibile creare o ResourceGraphDefinitions definire modelli personalizzati APIs e crearne APIs delle istanze.

**Nota**  
La voce di accesso creata automaticamente include la voce `AmazonEKSKROPolicy` che concede a kro le autorizzazioni di gestione ResourceGraphDefinitions e le relative istanze. Per consentire a kro di creare le risorse Kubernetes sottostanti definite nell'utente ResourceGraphDefinitions (come le risorse Deployments, Services o ACK), è necessario configurare politiche di accesso aggiuntive. Per ulteriori informazioni sulle voci di accesso e su come configurare autorizzazioni aggiuntive, consulta e. [Configura le autorizzazioni kro](kro-permissions.md) [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)

## Fasi successive
<a name="_next_steps"></a>

Dopo aver creato la funzionalità kro:
+  [concetti kro](kro-concepts.md)- Comprendi i concetti di kro e la composizione delle risorse
+  [concetti kro](kro-concepts.md)- Scopri SimpleSchema le espressioni CEL e i modelli di composizione delle risorse

# Crea una funzionalità kro utilizzando la console
<a name="kro-create-console"></a>

Questo argomento descrive come creare una funzionalità kro (Kube Resource Orchestrator) utilizzando. Console di gestione AWS

## Crea la funzionalità kro
<a name="_create_the_kro_capability"></a>

1. Apri la console Amazon EKS a https://console.aws.amazon.com/eks/ home\$1/clusters.

1. Seleziona il nome del cluster per aprire la pagina dei dettagli del cluster.

1. Scegli la scheda **Funzionalità**.

1. Nella barra di navigazione a sinistra, scegli **kro (Kube Resource Orchestrator**).

1. **Scegli la funzionalità Create kro.**

1. Per **IAM Capability Role**:
   + Se disponi già di un IAM Capability Role, selezionalo dal menu a discesa
   + Se devi creare un ruolo, scegli **Create kro** role 

     Questo apre la console IAM in una nuova scheda con policy di fiducia precompilate. Il ruolo non richiede autorizzazioni IAM aggiuntive poiché kro opera interamente all'interno del tuo cluster.

     Dopo aver creato il ruolo, torna alla console EKS e il ruolo verrà selezionato automaticamente.
**Nota**  
A differenza di ACK e Argo CD, kro non richiede autorizzazioni IAM aggiuntive oltre alla politica di fiducia. kro opera interamente all'interno del cluster e non effettua chiamate API. AWS 

1. Scegli **Create** (Crea).

Inizia il processo di creazione delle funzionalità.

## Verifica che la funzionalità sia attiva
<a name="_verify_the_capability_is_active"></a>

1. Nella scheda **Funzionalità**, visualizza lo stato delle capacità di kro.

1. Attendi che lo stato cambi da `CREATING` a`ACTIVE`.

1. Una volta attiva, la funzionalità è pronta per l'uso.

Per informazioni sullo stato delle funzionalità e sulla risoluzione dei problemi, vedere[Lavorare con le risorse di capacità](working-with-capabilities.md).

## Concedi le autorizzazioni per gestire le risorse Kubernetes
<a name="_grant_permissions_to_manage_kubernetes_resources"></a>

Quando crei una funzionalità kro, viene creato automaticamente un EKS Access Entry con`AmazonEKSKROPolicy`, che consente a kro di gestire e le relative istanze. ResourceGraphDefinitions Tuttavia, per impostazione predefinita non viene concessa alcuna autorizzazione per creare le risorse Kubernetes sottostanti (come Deployments, Services, ecc.) definite nel tuo. ConfigMaps ResourceGraphDefinitions

Questa progettazione intenzionale segue il principio del privilegio minimo: diversi richiedono autorizzazioni diverse. ResourceGraphDefinitions Devi configurare in modo esplicito le autorizzazioni o le esigenze in base alle risorse che gestirai. ResourceGraphDefinitions 

Per iniziare rapidamente, in ambienti di test o sviluppo, usa: `AmazonEKSClusterAdminPolicy`

1. Nella console EKS, accedi alla scheda **Accesso** del cluster.

1. In **Voci di accesso**, trova la voce relativa al tuo ruolo kro capability (avrà il ruolo ARN che hai creato in precedenza).

1. Scegli la voce di accesso per aprirne i dettagli.

1. Nella sezione **Politiche di accesso**, scegli **Associa politica di accesso**.

1. Seleziona `AmazonEKSClusterAdminPolicy` dall'elenco delle politiche.

1. Per **l'ambito di accesso**, seleziona **Cluster**.

1. Selezionare **Associate (Associa)**.

**Importante**  
`AmazonEKSClusterAdminPolicy`Concede ampie autorizzazioni per creare e gestire tutte le risorse Kubernetes, inclusa la possibilità di creare qualsiasi tipo di risorsa in tutti i namespace. Questa funzionalità è utile per lo sviluppo, ma non deve essere utilizzata in produzione POCs . Per la produzione, crea politiche RBAC personalizzate che concedano solo le autorizzazioni necessarie per le ResourceGraphDefinitions risorse specifiche che gestirai. Per indicazioni sulla configurazione delle autorizzazioni con privilegi minimi, consulta e. [Configura le autorizzazioni kro](kro-permissions.md) [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)

## Verifica che siano disponibili risorse personalizzate
<a name="_verify_custom_resources_are_available"></a>

Dopo che la funzionalità è attiva, verifica che le risorse personalizzate kro siano disponibili nel tuo cluster.

 **Utilizzo della console** 

1. Accedi al tuo cluster nella console Amazon EKS

1. Scegli la scheda **Risorse**

1. Scegli **Estensioni** 

1. Scegliere **CustomResourceDefinitions** 

Dovresti vedere il tipo di `ResourceGraphDefinition` risorsa elencato.

 **Usare kubectl** 

```
kubectl api-resources | grep kro.run
```

Dovresti vedere il tipo di `ResourceGraphDefinition` risorsa elencato.

## Fasi successive
<a name="_next_steps"></a>
+  [concetti kro](kro-concepts.md)- Comprendi i concetti kro e la composizione delle risorse
+  [concetti kro](kro-concepts.md)- Scopri SimpleSchema le espressioni CEL e i modelli di composizione
+  [Lavorare con le risorse di capacità](working-with-capabilities.md)- Gestisci la tua risorsa kro Capability

# Crea una funzionalità kro utilizzando la CLI AWS
<a name="kro-create-cli"></a>

Questo argomento descrive come creare una funzionalità kro (Kube Resource Orchestrator) utilizzando la CLI. AWS 

## Prerequisiti
<a name="_prerequisites"></a>
+  ** AWS CLI**: versione `2.12.3` o successiva. Per verificare la tua versione, `aws --version` esegui. Per ulteriori informazioni, consulta la Guida per l'utente all'[installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) nell'interfaccia a riga di AWS comando.
+  **`kubectl`**— Uno strumento da riga di comando per lavorare con i cluster Kubernetes. Per ulteriori informazioni, consulta [Impostazione di `kubectl` e `eksctl`](install-kubectl.md).

## Fase 1: creazione di un ruolo IAM Capability
<a name="_step_1_create_an_iam_capability_role"></a>

Crea un file di policy di fiducia:

```
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
```

Crea il ruolo IAM:

```
aws iam create-role \
  --role-name KROCapabilityRole \
  --assume-role-policy-document file://kro-trust-policy.json
```

**Nota**  
A differenza di ACK e Argo CD, kro non richiede autorizzazioni IAM aggiuntive. kro opera interamente all'interno del cluster e non effettua chiamate API. AWS Il ruolo è necessario solo per stabilire un rapporto di fiducia con il servizio EKS Capabilities.

## Fase 2: Creare la funzionalità kro
<a name="_step_2_create_the_kro_capability"></a>

Crea la risorsa di funzionalità kro sul tuo cluster. Sostituiscilo *region-code* con la AWS regione in cui si trova il cluster (ad esempio`us-west-2`) e *my-cluster* con il nome del 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
```

Il comando viene restituito immediatamente, ma la funzionalità impiega del tempo per diventare attiva poiché EKS crea l'infrastruttura e i componenti di funzionalità richiesti. EKS installerà le Kubernetes Custom Resource Definitions relative a questa funzionalità nel cluster non appena viene creata.

**Nota**  
Se ricevi un errore che indica che il cluster non esiste o non disponi delle autorizzazioni, verifica:  
Il nome del cluster è corretto
La tua AWS CLI è configurata per la regione corretta
Disponi delle autorizzazioni IAM richieste

## Fase 3: Verifica che la funzionalità sia attiva
<a name="_step_3_verify_the_capability_is_active"></a>

Attendi che la funzionalità diventi attiva. Sostituiscilo *region-code* con la AWS regione in cui si trova il cluster e sostituiscilo *my-cluster* con il nome del cluster.

```
aws eks describe-capability \
  --region region-code \
  --cluster-name my-cluster \
  --capability-name my-kro \
  --query 'capability.status' \
  --output text
```

La funzionalità è pronta quando viene visualizzato lo stato`ACTIVE`.

Puoi anche visualizzare i dettagli completi delle funzionalità:

```
aws eks describe-capability \
  --region region-code \
  --cluster-name my-cluster \
  --capability-name my-kro
```

## Passaggio 4: concedere le autorizzazioni per gestire le risorse Kubernetes
<a name="_step_4_grant_permissions_to_manage_kubernetes_resources"></a>

Quando crei una funzionalità kro, viene creato automaticamente un EKS Access Entry con`AmazonEKSKROPolicy`, che consente a kro di gestire e le relative istanze. ResourceGraphDefinitions Tuttavia, per impostazione predefinita non viene concessa alcuna autorizzazione per creare le risorse Kubernetes sottostanti (come Deployments, Services, ecc.) definite nel tuo. ConfigMaps ResourceGraphDefinitions

Questa progettazione intenzionale segue il principio del privilegio minimo: diversi richiedono autorizzazioni diverse. ResourceGraphDefinitions Ad esempio: \$1 A ResourceGraphDefinition che crea solo risorse ACK ConfigMaps e Secrets necessita di autorizzazioni diverse rispetto a una che crea distribuzioni e servizi \$1 A ResourceGraphDefinition che crea risorse ACK necessita delle autorizzazioni per quelle risorse personalizzate specifiche \$1 Alcuni potrebbero ResourceGraphDefinitions leggere solo le risorse esistenti senza crearne di nuove

È necessario configurare in modo esplicito le autorizzazioni o le esigenze in base alle risorse che gestirai. ResourceGraphDefinitions 

### Configurazione rapida
<a name="_quick_setup"></a>

Per iniziare rapidamente, in ambienti di test o sviluppo, usa: `AmazonEKSClusterAdminPolicy`

Ottieni il ruolo di capacità ARN:

```
CAPABILITY_ROLE_ARN=$(aws eks describe-capability \
  --region region-code \
  --cluster-name my-cluster \
  --capability-name my-kro \
  --query 'capability.roleArn' \
  --output text)
```

Associa la politica di amministrazione del 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
```

**Importante**  
`AmazonEKSClusterAdminPolicy`Concede ampie autorizzazioni per creare e gestire tutte le risorse Kubernetes, inclusa la possibilità di creare qualsiasi tipo di risorsa in tutti i namespace. Questa funzionalità è utile per lo sviluppo, ma non deve essere utilizzata in produzione POCs . Per la produzione, crea politiche RBAC personalizzate che concedano solo le autorizzazioni necessarie per le ResourceGraphDefinitions risorse specifiche che gestirai. Per indicazioni sulla configurazione delle autorizzazioni con privilegi minimi, consulta e. [Configura le autorizzazioni kro](kro-permissions.md) [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)

## Passaggio 5: Verifica della disponibilità di risorse personalizzate
<a name="_step_5_verify_custom_resources_are_available"></a>

Dopo che la funzionalità è attiva, verifica che le risorse personalizzate kro siano disponibili nel tuo cluster:

```
kubectl api-resources | grep kro.run
```

Dovresti vedere il tipo di `ResourceGraphDefinition` risorsa elencato.

## Fasi successive
<a name="_next_steps"></a>
+  [concetti kro](kro-concepts.md)- Comprendi i concetti kro e la composizione delle risorse
+  [concetti kro](kro-concepts.md)- Scopri SimpleSchema le espressioni CEL e i modelli di composizione
+  [Lavorare con le risorse di capacità](working-with-capabilities.md)- Gestisci la tua risorsa kro Capability

# Crea una funzionalità kro usando eksctl
<a name="kro-create-eksctl"></a>

Questo argomento descrive come creare una funzionalità kro (Kube Resource Orchestrator) usando eksctl.

**Nota**  
I seguenti passaggi richiedono la versione eksctl o successiva. `0.220.0` Per verificare la tua versione, esegui. `eksctl version`

## Fase 1: Creare un ruolo di capacità IAM
<a name="_step_1_create_an_iam_capability_role"></a>

Crea un file di policy di fiducia:

```
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
```

Crea il ruolo IAM:

```
aws iam create-role \
  --role-name KROCapabilityRole \
  --assume-role-policy-document file://kro-trust-policy.json
```

**Nota**  
A differenza di ACK e Argo CD, kro non richiede autorizzazioni IAM aggiuntive oltre alla policy di fiducia. kro opera interamente all'interno del cluster e non effettua chiamate API. AWS 

## Fase 2: Creare la funzionalità kro
<a name="_step_2_create_the_kro_capability"></a>

Crea la funzionalità kro usando eksctl. Sostituiscilo *region-code* con la AWS regione in cui si trova il cluster e sostituiscilo *my-cluster* con il nome del cluster.

```
eksctl create capability \
  --region region-code \
  --cluster my-cluster \
  --name my-kro \
  --type KRO \
  --role-arn arn:aws:iam::[.replaceable]111122223333:role/KROCapabilityRole
```

Il comando viene restituito immediatamente, ma la funzionalità impiega del tempo per diventare attiva.

## Fase 3: Verificare che la funzionalità sia attiva
<a name="_step_3_verify_the_capability_is_active"></a>

Verifica lo stato della capacità. Sostituiscilo *region-code* con la AWS regione in cui si trova il cluster e sostituiscilo *my-cluster* con il nome del cluster.

```
eksctl get capability \
  --region region-code \
  --cluster my-cluster \
  --name my-kro
```

La funzionalità è pronta quando viene visualizzato lo stato`ACTIVE`.

## Passaggio 4: concedere le autorizzazioni per gestire le risorse Kubernetes
<a name="_step_4_grant_permissions_to_manage_kubernetes_resources"></a>

Per impostazione predefinita, kro può solo creare e gestire le relative istanze. ResourceGraphDefinitions Per consentire a kro di creare e gestire le risorse Kubernetes sottostanti definite nel tuo ResourceGraphDefinitions, associa la policy di accesso alla voce di `AmazonEKSClusterAdminPolicy` accesso della funzionalità.

Ottieni il ruolo di capacità ARN:

```
CAPABILITY_ROLE_ARN=$(aws eks describe-capability \
  --region region-code \
  --cluster my-cluster \
  --name my-kro \
  --query 'capability.roleArn' \
  --output text)
```

Associa la politica di amministrazione del 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
```

**Importante**  
`AmazonEKSClusterAdminPolicy`Concede ampie autorizzazioni per creare e gestire tutte le risorse Kubernetes e ha lo scopo di semplificare l'avvio. Per l'uso in produzione, crea politiche RBAC più restrittive che concedano solo le autorizzazioni necessarie per le risorse specifiche che gestirai. ResourceGraphDefinitions Per indicazioni sulla configurazione delle autorizzazioni con privilegi minimi, consulta e. [Configura le autorizzazioni kro](kro-permissions.md) [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)

## Passaggio 5: Verifica della disponibilità di risorse personalizzate
<a name="_step_5_verify_custom_resources_are_available"></a>

Dopo che la funzionalità è attiva, verifica che le risorse personalizzate kro siano disponibili nel tuo cluster:

```
kubectl api-resources | grep kro.run
```

Dovresti vedere il tipo di `ResourceGraphDefinition` risorsa elencato.

## Fasi successive
<a name="_next_steps"></a>
+  [concetti kro](kro-concepts.md)- Comprendi i concetti kro e la composizione delle risorse
+  [concetti kro](kro-concepts.md)- Scopri SimpleSchema le espressioni CEL e i modelli di composizione
+  [Lavorare con le risorse di capacità](working-with-capabilities.md)- Gestisci la tua risorsa kro Capability

# concetti kro
<a name="kro-concepts"></a>

kro consente ai team della piattaforma di creare Kubernetes personalizzati APIs che compongono più risorse in astrazioni di livello superiore. Questo argomento illustra un esempio pratico, quindi spiega i concetti fondamentali da comprendere quando si lavora con EKS Capability for kro.

## Guida introduttiva a kro
<a name="_getting_started_with_kro"></a>

Dopo aver creato la funzionalità kro (vedi[Crea una funzionalità kro](create-kro-capability.md)), puoi iniziare a crearne un APIs utilizzo personalizzato ResourceGraphDefinitions nel tuo cluster.

Ecco un esempio completo che crea una semplice astrazione di un'applicazione web:

```
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
```

Dopo averlo applicato ResourceGraphDefinition, i team applicativi possono creare applicazioni Web utilizzando la vostra API semplificata:

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

kro crea automaticamente Deployment and Service con la configurazione appropriata. Poiché `image` non è specificato, utilizza il valore predefinito `nginx:latest` dello schema.

## Concetti principali
<a name="_core_concepts"></a>

**Importante**  
kro esegue la convalida ResourceGraphDefinitions al momento della creazione, non in fase di esecuzione. Quando crei un RGD, kro convalida la sintassi CEL, controlla il tipo delle espressioni rispetto agli schemi Kubernetes effettivi, verifica l'esistenza dei campi e rileva le dipendenze circolari. Ciò significa che gli errori vengono rilevati immediatamente quando si crea l'RGD, prima che qualsiasi istanza venga distribuita.

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

A ResourceGraphDefinition (RGD) definisce un'API Kubernetes personalizzata specificando:
+  **Schema**: la struttura dell'API che utilizza il SimpleSchema formato (nomi di campo, tipi, impostazioni predefinite, convalida)
+  **Risorse**: modelli per il Kubernetes sottostante o risorse da creare AWS 
+  **Dipendenze**: come le risorse si relazionano tra loro (rilevate automaticamente dai riferimenti di campo)

Quando applichi un RGD, kro registra una nuova Custom Resource Definition (CRD) nel tuo cluster. I team applicativi possono quindi creare istanze della vostra API personalizzata e kro si occupa della creazione e della gestione di tutte le risorse sottostanti.

Per ulteriori informazioni, consulta [ResourceGraphDefinition Panoramica nella documentazione](https://kro.run/docs/concepts/rgd/overview/) di kro.

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

SimpleSchema fornisce un modo semplificato per definire gli schemi API senza richiedere conoscenze su 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 supporta`string`, `integer``boolean`, e `number` tipi con vincoli come`required`,,/`default`, `minimum` e. `maximum` `enum` `pattern`

Per ulteriori informazioni, consulta la documentazione [SimpleSchema](https://kro.run/docs/concepts/rgd/schema/)di kro.

### espressioni CEL
<a name="_cel_expressions"></a>

kro utilizza il Common Expression Language (CEL) per fare riferimento ai valori in modo dinamico e aggiungere logica condizionale. Le espressioni CEL sono racchiuse `${` `}` e possono essere utilizzate in due modi:

 **Espressioni autonome** - L'intero valore del campo è una singola espressione:

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

Il risultato dell'espressione sostituisce l'intero valore del campo e deve corrispondere al tipo previsto del campo.

 **Modelli di stringhe**: una o più espressioni incorporate in una stringa:

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

Tutte le espressioni nei modelli di stringhe devono restituire stringhe. Usa `string()` per convertire altri tipi:`"replicas-${string(schema.spec.count)}"`.

 **Riferimenti sui campi**: accedi ai valori delle specifiche dell'istanza utilizzando`schema.spec`:

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

 **Accesso facoltativo ai campi**: da utilizzare `?` per campi che potrebbero non esistere:

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

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

Se il campo non esiste, l'espressione restituisce `null` invece di fallire.

 **Risorse condizionali**: includi le risorse solo quando sono soddisfatte le condizioni:

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

Il `includeWhen` campo accetta un elenco di espressioni booleane. Tutte le condizioni devono essere vere affinché la risorsa possa essere creata. Attualmente, `includeWhen` può fare riferimento solo `schema.spec` ai campi.

 **Trasformazioni** - Trasforma i valori utilizzando operatori e funzioni ternari:

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

 **Riferimenti tra risorse** - Valori di riferimento provenienti da altre risorse:

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

Quando si fa riferimento a un'altra risorsa in un'espressione CEL, si crea automaticamente una dipendenza. kro assicura che la risorsa referenziata venga creata per prima.

Per ulteriori informazioni, consulta [CEL Expressions](https://kro.run/docs/concepts/rgd/cel-expressions/) nella documentazione di kro.

### Dipendenze tra le risorse
<a name="_resource_dependencies"></a>

kro deduce automaticamente le dipendenze dalle espressioni CEL: non si specifica l'ordine, si descrivono le relazioni. Quando una risorsa fa riferimento a un'altra utilizzando un'espressione CEL, kro crea una dipendenza e determina l'ordine di creazione corretto.

```
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'espressione `${bucket.spec.name}` crea una dipendenza. kro crea un grafico aciclico diretto (DAG) di tutte le risorse e le relative dipendenze, quindi calcola un ordine topologico per la creazione.

 **Ordine di creazione: le risorse vengono create in ordine topologico** (prima le dipendenze).

 **Creazione parallela**: le risorse senza dipendenze vengono create contemporaneamente.

 **Ordine di eliminazione**: le risorse vengono eliminate in ordine topologico inverso (prima le persone dipendenti).

 **Dipendenze circolari**: non consentite: kro rifiuta con dipendenze circolari durante la convalida. ResourceGraphDefinitions 

È possibile visualizzare l'ordine di creazione calcolato:

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

Per maggiori informazioni, vedi [Inferenza del grafico nella documentazione](https://kro.run/docs/concepts/rgd/dependencies-ordering/) di kro.

## Composizione con ACK
<a name="_composing_with_ack"></a>

kro funziona perfettamente con EKS Capability for ACK per comporre AWS risorse con risorse 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}
```

Questo modello consente di creare AWS risorse, estrarne i dettagli (ARNs URLs, endpoint) e inserirle nella configurazione dell'applicazione, il tutto gestito come una singola unità.

Per ulteriori schemi di composizione ed esempi avanzati, consulta. [considerazioni kro per EKS](kro-considerations.md)

## Fasi successive
<a name="_next_steps"></a>
+  [considerazioni kro per EKS](kro-considerations.md)- Scopri i pattern specifici di EKS, l'RBAC e l'integrazione con ACK e Argo CD
+  [kro Documentation - Documentazione](https://kro.run/docs/overview) kro completa che include espressioni CEL avanzate, modelli di convalida e risoluzione dei problemi

# Configura le autorizzazioni kro
<a name="kro-permissions"></a>

A differenza di ACK e Argo CD, kro non richiede autorizzazioni IAM. kro opera interamente all'interno del cluster Kubernetes e non effettua chiamate API. AWS Controlla l'accesso alle risorse kro utilizzando Kubernetes RBAC standard.

## Come funzionano le autorizzazioni con kro
<a name="_how_permissions_work_with_kro"></a>

kro utilizza due tipi di risorse Kubernetes con ambiti diversi:

 **ResourceGraphDefinitions**: risorse con ambito cluster che definiscono la personalizzazione. APIs In genere gestite dai team della piattaforma che progettano e gestiscono gli standard organizzativi.

 **Istanze: risorse** personalizzate con ambito namespace create da. ResourceGraphDefinitions Può essere creato da team di applicazioni con autorizzazioni RBAC appropriate.

Per impostazione predefinita, la funzionalità kro dispone delle autorizzazioni per gestire le relative istanze tramite ResourceGraphDefinitions la politica di accesso. `AmazonEKSKROPolicy` Tuttavia, kro richiede autorizzazioni aggiuntive per creare e gestire le risorse Kubernetes sottostanti definite nell'utente ResourceGraphDefinitions (come Deployments, Services o risorse ACK). È necessario concedere queste autorizzazioni tramite le politiche di accesso o Kubernetes RBAC. [Per i dettagli sulla concessione di queste autorizzazioni, consulta kro arbitrary resource permissions.](capabilities-security.md#kro-resource-permissions)

## Autorizzazioni del team della piattaforma
<a name="_platform_team_permissions"></a>

I team della piattaforma necessitano delle autorizzazioni per creare e gestire. ResourceGraphDefinitions

 **Esempio ClusterRole per i team della piattaforma**:

```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kro-platform-admin
rules:
- apiGroups: ["kro.run"]
  resources: ["resourcegraphdefinitions"]
  verbs: ["*"]
```

 **Associati ai membri del team della piattaforma**:

```
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
```

## Autorizzazioni del team dell'applicazione
<a name="_application_team_permissions"></a>

I team applicativi necessitano delle autorizzazioni per creare istanze di risorse personalizzate nei propri namespace.

 **Esempio** di ruolo per i team delle applicazioni:

```
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"]
```

 **Associarsi ai membri del team applicativo**:

```
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
```

**Nota**  
Il gruppo di API nel ruolo (`kro.run`in questo esempio) deve corrispondere a quello `apiVersion` definito nello schema ResourceGraphDefinition dell'utente.

## Accesso in sola lettura
<a name="_read_only_access"></a>

Concedi l'accesso in sola lettura alla visualizzazione ResourceGraphDefinitions e alle istanze senza autorizzazioni di modifica.

 ** ClusterRoleSola** lettura:

```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kro-viewer
rules:
- apiGroups: ["kro.run"]
  resources: ["resourcegraphdefinitions"]
  verbs: ["get", "list", "watch"]
```

 Ruolo di **sola lettura per** le istanze:

```
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"]
```

## Accesso a più namespace
<a name="_multi_namespace_access"></a>

Concedi ai team delle applicazioni l'accesso a più namespace utilizzando with. ClusterRoles RoleBindings

 **ClusterRole per** l'accesso a più namespace:

```
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"]
```

 **Associa a namespace** specifici:

```
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
```

## Best practice
<a name="_best_practices"></a>

 **Principio del privilegio minimo**: concedi solo le autorizzazioni minime necessarie per le responsabilità di ogni team.

 **Usa i gruppi anziché i singoli utenti**: associa i ruoli ai gruppi anziché ai singoli utenti per una gestione più semplice.

 **Aspetti distinti relativi alla piattaforma e all'applicazione:** i team della piattaforma gestiscono le istanze ResourceGraphDefinitions, i team delle applicazioni gestiscono le istanze.

 **Isolamento dello spazio dei nomi**: utilizza i namespace per isolare team o ambienti diversi, con RBAC che controlla l'accesso a ciascun namespace.

 Accesso in **sola lettura per il controllo: Fornisci l'accesso in sola lettura ai team di sicurezza e conformità per scopi di controllo.**

## Fasi successive
<a name="_next_steps"></a>
+  [concetti kro](kro-concepts.md)- Comprendi i concetti kro e la composizione delle risorse
+  [concetti kro](kro-concepts.md)- Comprendi SimpleSchema, le espressioni CEL e i modelli di composizione
+  [Considerazioni sulla sicurezza per EKS Capabilities](capabilities-security.md)- Esamina le migliori pratiche di sicurezza per quanto riguarda le funzionalità

# considerazioni kro per EKS
<a name="kro-considerations"></a>

Questo argomento tratta importanti considerazioni sull'utilizzo di EKS Capability per kro, tra cui quando utilizzare la composizione delle risorse, i modelli RBAC e l'integrazione con altre funzionalità EKS.

## Quando usare kro
<a name="_when_to_use_kro"></a>

kro è progettato per creare modelli di infrastruttura riutilizzabili e personalizzati APIs che semplificano la gestione delle risorse complesse.

 **Usa kro quando hai bisogno** di:
+ Crea piattaforme self-service semplificate per i team applicativi APIs 
+ Standardizza i modelli di infrastruttura tra i team (database, backup e monitoraggio)
+ Gestisci le dipendenze delle risorse e trasferisci i valori tra le risorse
+ Crea astrazioni personalizzate che nascondono la complessità dell'implementazione
+ Componi più risorse ACK in blocchi costitutivi di livello superiore
+ Abilita i GitOps flussi di lavoro per stack di infrastrutture complessi

 **Non usare kro quando:**
+ Gestione di risorse semplici e autonome (usa direttamente le risorse ACK o Kubernetes)
+ È necessaria una logica di runtime dinamica (kro è dichiarativo, non imperativo)
+ Le risorse non hanno dipendenze o configurazioni condivise

kro eccelle nella creazione di «percorsi asfaltati», schemi ponderati e riutilizzabili che consentono ai team di implementare correttamente infrastrutture complesse.

## Schemi RBAC
<a name="_rbac_patterns"></a>

kro consente la separazione delle preoccupazioni tra i team della piattaforma che creano le istanze ResourceGraphDefinitions e i team delle applicazioni che creano le istanze.

### Responsabilità del team di piattaforma
<a name="_platform_team_responsibilities"></a>

I team della piattaforma creano e gestiscono ResourceGraphDefinitions (RGDs) che definiscono la personalizzazione APIs.

 **Autorizzazioni necessarie**:
+ Crea, aggiorna, elimina ResourceGraphDefinitions
+ Gestisci i tipi di risorse sottostanti (implementazioni, servizi, risorse ACK)
+ Accesso a tutti i namespace in cui verranno utilizzati RGDs 

 **Esempio ClusterRole per** il team della piattaforma:

```
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"]
```

Per una configurazione RBAC dettagliata, vedere. [Configura le autorizzazioni kro](kro-permissions.md)

### Responsabilità del team di applicazione
<a name="_application_team_responsibilities"></a>

I team applicativi creano istanze di risorse personalizzate definite da RGDs senza la necessità di comprenderne la complessità sottostante.

 **Autorizzazioni necessarie:**
+ Creare, aggiornare ed eliminare istanze di risorse personalizzate
+ Accesso in lettura al loro namespace
+ Nessun accesso alle risorse sottostanti o RGDs

 **Vantaggi**:
+ I team utilizzano strumenti semplici e di alto livello APIs
+ I team della piattaforma controllano i dettagli dell'implementazione
+ Riduzione del rischio di errori di configurazione
+ Onboarding più rapido per i nuovi membri del team

## Integrazione con altre funzionalità EKS
<a name="_integration_with_other_eks_capabilities"></a>

### Composizione di risorse ACK
<a name="_composing_ack_resources"></a>

kro è particolarmente potente se combinato con ACK per creare modelli di infrastruttura.

 **Schemi comuni**:
+  **Applicazione con archiviazione**: bucket S3\$1coda SQS\$1configurazione delle notifiche
+  **Stack di database**: istanza RDS \$1 gruppo di parametri \$1 gruppo di sicurezza \$1 segreto Secrets Manager
+  **Rete**: VPC \$1 sottoreti \$1 tabelle di routing \$1 gruppi di sicurezza \$1 gateway NAT
+  Elaborazione **con storage**: EC2 istanza \$1 volumi EBS \$1 profilo di istanza IAM

kro gestisce l'ordine delle dipendenze, passa i valori tra le risorse (come le stringhe di connessione) ARNs e gestisce l'intero ciclo di vita come una singola unità.

Per esempi di composizione di risorse ACK, vedi. [Concetti ACK](ack-concepts.md)

### GitOps con Argo CD
<a name="_gitops_with_argo_cd"></a>

Usa il CD EKS Capability for Argo per distribuire entrambe le RGDs istanze dai repository Git.

 Organizzazione **del** repository:
+  **Repo della piattaforma**: contiene contenuti ResourceGraphDefinitions gestiti dal team della piattaforma
+  **Repo di applicazioni**: contengono istanze di risorse personalizzate gestite dai team delle app
+  **Repo condiviso**: contiene sia le istanze che le istanze per le RGDs organizzazioni più piccole

 **Considerazioni:**
+ Implementa RGDs prima delle istanze (le onde di sincronizzazione di Argo CD possono esserti utili)
+ Utilizzate progetti Argo CD separati per i team di piattaforme e applicazioni
+ Il team della piattaforma controlla l'accesso al repository RGD
+ I team applicativi hanno accesso in sola lettura alle definizioni RGD

Per ulteriori informazioni su Argo CD, vedere. [Lavorare con Argo CD](working-with-argocd.md)

## Organizzando ResourceGraphDefinitions
<a name="_organizing_resourcegraphdefinitions"></a>

 RGDs Organizza per scopo, complessità e proprietà.

 **Per scopo**:
+  **Infrastruttura**: stack di database, rete, archiviazione
+  **Applicazione**: app Web APIs, lavori in batch
+  **Piattaforma**: servizi condivisi, monitoraggio, registrazione

 **Per complessità**:
+  **Semplice**: 2-3 risorse con dipendenze minime
+  **Moderato**: 5-10 risorse con alcune dipendenze
+  **Complesso: più** di 10 risorse con dipendenze complesse

 Convenzioni di **denominazione:**
+ Usa nomi descrittivi:, `webapp-with-database` `s3-notification-queue` 
+ Includi la versione nel nome per annullare le modifiche: `webapp-v2` 
+ Usa prefissi coerenti RGDs per: `platform- ` `app-` 

 **Strategia del namespace**:
+ RGDs sono con ambito cluster (non con namespace)
+ Le istanze hanno uno spazio dei nomi
+ Usa i selettori dello spazio dei nomi per controllare dove è possibile creare le istanze RGDs 

## Controllo delle versioni e aggiornamenti
<a name="_versioning_and_updates"></a>

Piano per l'evoluzione di RGD e la migrazione delle istanze.

 **Aggiornamenti RGD:**
+  **Modifiche continue**: aggiorna RGD in atto (aggiungi campi opzionali, nuove risorse con IncludeWhen)
+  **Ultime modifiche**: crea un nuovo RGD con un nome diverso (webapp-v2)
+  **Deprecazione: contrassegna il vecchio con annotazioni**, comunica la cronologia della migrazione RGDs 

 **Migrazione delle istanze:**
+ Crea nuove istanze con RGD aggiornato
+ Convalida il corretto funzionamento delle nuove istanze
+ Elimina le vecchie istanze
+ kro gestisce automaticamente gli aggiornamenti delle risorse sottostanti

 **Migliori pratiche**:
+ Verifica innanzitutto le modifiche RGD in ambienti non di produzione
+ Usa il controllo semantico delle versioni nei nomi RGD per le modifiche principali
+ Modifiche di interruzione dei documenti e percorsi di migrazione
+ Fornisci esempi di migrazione per i team applicativi

## Convalida e test
<a name="_validation_and_testing"></a>

Convalida RGDs prima dell'implementazione in produzione.

 Strategie di **convalida**:
+  **Convalida dello schema: kro convalida** automaticamente la struttura RGD
+  Istanze **dry-run: crea istanze** di test nei namespace di sviluppo
+  **Test di integrazione**: verifica che le risorse composte funzionino insieme
+  **Applicazione delle politiche**: utilizza i controller di ammissione per far rispettare gli standard organizzativi

 **Problemi comuni da** testare:
+ Dipendenze e ordinamento delle risorse
+ Scambio di valore tra risorse (espressioni CEL)
+ Inclusione condizionale delle risorse (includeWhen)
+ Propagazione dello stato dalle risorse sottostanti
+ Autorizzazioni RBAC, ad esempio la creazione

## Documentazione upstream
<a name="_upstream_documentation"></a>

Per informazioni dettagliate sull'uso di kro:
+  [Guida introduttiva a kro - Creazione](https://kro.run/docs/guides/getting-started) ResourceGraphDefinitions
+  [Espressioni CEL - Scrittura di espressioni](https://kro.run/docs/concepts/cel) CEL
+  [kro Guides](https://kro.run/docs/guides/) - Modelli di composizione avanzati
+  [Risoluzione dei problemi - Risoluzione](https://kro.run/docs/troubleshooting) dei problemi e debug

## Fasi successive
<a name="_next_steps"></a>
+  [Configura le autorizzazioni kro](kro-permissions.md)- Configura RBAC per i team di piattaforme e applicazioni
+  [concetti kro](kro-concepts.md)- Comprendi i concetti kro e il ciclo di vita delle risorse
+  [Risolvi i problemi relativi alle funzionalità kro](kro-troubleshooting.md)- Risolvi i problemi di kro
+  [Concetti ACK](ack-concepts.md)- Scopri le risorse ACK per la composizione
+  [Lavorare con Argo CD](working-with-argocd.md)- Distribuzione RGDs e istanze con GitOps

# Risolvi i problemi relativi alle funzionalità kro
<a name="kro-troubleshooting"></a>

Questo argomento fornisce linee guida per la risoluzione dei problemi di EKS Capability for kro, compresi i controlli dello stato delle capacità, le autorizzazioni RBAC, gli errori di espressione CEL e i problemi di composizione delle risorse.

**Nota**  
Le funzionalità EKS sono completamente gestite ed eseguite all'esterno del cluster. Non hai accesso ai log dei controller o al `kro-system` namespace. La risoluzione dei problemi si concentra sullo stato delle funzionalità, sulla configurazione RBAC e sullo stato delle risorse.

## Le funzionalità sono ATTIVE ma ResourceGraphDefinitions non funzionano
<a name="_capability_is_active_but_resourcegraphdefinitions_arent_working"></a>

Se la tua funzionalità kro mostra `ACTIVE` lo stato ma ResourceGraphDefinitions non stai creando risorse sottostanti, controlla lo stato della capacità, le autorizzazioni RBAC e lo stato delle risorse.

 **Verifica lo stato delle capacità:**

È possibile visualizzare i problemi relativi allo stato e allo stato delle funzionalità nella console EKS o utilizzando la AWS CLI.

 **Console**:

1. Apri la console Amazon EKS a https://console.aws.amazon.com/eks/ home\$1/clusters.

1. Seleziona il nome del cluster.

1. Scegli la scheda **Osservabilità**.

1. Scegli **Monitora cluster**.

1. Scegli la scheda **Capacità** per visualizzare lo stato e lo stato di tutte le funzionalità.

 ** 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
```

 Cause comuni:
+  Autorizzazioni **RBAC mancanti: kro non dispone delle autorizzazioni** per creare le risorse Kubernetes sottostanti
+  **Espressioni CEL** non valide: errori di sintassi in ResourceGraphDefinition
+  **Dipendenze dalle risorse**: risorse dipendenti non pronte
+  **Convalida dello schema: l'**istanza non soddisfa i requisiti dello schema RGD

 **Verifica le autorizzazioni RBAC:**

```
# Check if capability has cluster admin policy
kubectl get accessentry -A | grep kro
```

Se la funzionalità non dispone delle autorizzazioni richieste, associala alla voce di accesso della `AmazonEKSClusterAdminPolicy` funzionalità kro o crea politiche RBAC più restrittive per l'uso in produzione. Per informazioni dettagliate, vedi [Configura le autorizzazioni kro](kro-permissions.md).

 **Verifica lo stato: ResourceGraphDefinition **

```
# 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 hanno tre condizioni di stato chiave:
+  `ResourceGraphAccepted`- Se l'RGD ha superato la convalida (sintassi CEL, controllo del tipo, esistenza del campo)
+  `KindReady`- Se il CRD per l'API personalizzata è stato generato e registrato
+  `ControllerReady`- Se kro sta monitorando attivamente le istanze della tua API personalizzata

In caso `ResourceGraphAccepted` affermativo`False`, controllate il messaggio relativo alla condizione per eventuali errori di convalida, ad esempio campi sconosciuti, mancate corrispondenze tra i tipi o dipendenze circolari.

## Istanze create ma le risorse sottostanti non vengono visualizzate
<a name="_instances_created_but_underlying_resources_not_appearing"></a>

Se esistono istanze di risorse personalizzate ma le risorse Kubernetes sottostanti (Deployments, Services ConfigMaps) non vengono create, verifica che kro disponga delle autorizzazioni e verifica la presenza di errori di composizione.

 Controlla lo stato dell'**istanza**:

```
# 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}'
```

Le istanze hanno un `state` campo che mostra lo stato di alto livello:
+  `ACTIVE`- L'istanza viene eseguita correttamente
+  `IN_PROGRESS`- L'istanza è in fase di elaborazione o riconciliazione
+  `FAILED`- Impossibile riconciliare l'istanza
+  `DELETING`- L'istanza viene eliminata
+  `ERROR`- Si è verificato un errore durante l'elaborazione

Le istanze hanno anche quattro condizioni di stato:
+  `InstanceManaged`- I finalizzatori e le etichette sono impostati correttamente
+  `GraphResolved`- Grafico di runtime creato e risorse risolte
+  `ResourcesReady`- Tutte le risorse create e pronte
+  `Ready`- Stato generale dell'istanza (lo diventa solo `True` quando tutte le condizioni secondarie lo sono`True`)

Concentrati sulla `Ready` condizione per determinare lo stato dell'istanza. In caso `Ready` `False` affermativo, controlla le condizioni secondarie per identificare quale fase non è riuscita.

 **Verifica le autorizzazioni RBAC:**

La funzionalità kro richiede le autorizzazioni per creare le risorse Kubernetes sottostanti definite nel tuo. ResourceGraphDefinitions

```
# Check if the capability has the AmazonEKSClusterAdminPolicy
kubectl get accessentry -A | grep kro
```

Se mancano le autorizzazioni, associale alla voce di accesso della `AmazonEKSClusterAdminPolicy` funzionalità kro o crea politiche RBAC più restrittive per l'uso in produzione. Per informazioni dettagliate, vedi [Configura le autorizzazioni kro](kro-permissions.md).

## Errori di espressione CEL
<a name="_cel_expression_errors"></a>

Gli errori delle espressioni CEL vengono rilevati al momento ResourceGraphDefinition della creazione, non al momento della creazione delle istanze. kro convalida tutta la sintassi CEL, controlla i tipi delle espressioni rispetto agli schemi Kubernetes e verifica l'esistenza dei campi quando crei l'RGD.

 **Errori comuni** di convalida CEL:
+  Riferimento al **campo non definito: riferimento** a un campo che non esiste nello schema o nella risorsa
+  **Mancata corrispondenza del tipo**: l'espressione restituisce un tipo errato (ad esempio, stringa in cui è previsto un numero intero)
+  **Sintassi non valida**: parentesi, virgolette o operatori mancanti nell'espressione CEL
+  **Tipo di risorsa sconosciuto**: riferimento a un CRD che non esiste nel cluster

 **Verifica lo stato di convalida 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
```

In caso `ResourceGraphAccepted` `False` affermativo, il messaggio di condizione contiene l'errore di convalida.

 **Esempi di espressioni CEL valide**:

```
# 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}
```

## Le dipendenze delle risorse non si risolvono
<a name="_resource_dependencies_not_resolving"></a>

kro deduce automaticamente le dipendenze dalle espressioni CEL e crea le risorse nell'ordine corretto. Se le risorse non vengono create come previsto, controlla l'ordine di dipendenza e la disponibilità delle risorse.

 **Visualizza l'ordine di creazione calcolato**:

```
# See the order kro will create resources
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.topologicalOrder}'
```

Questo mostra l'ordine calcolato in base ai riferimenti delle espressioni CEL tra le risorse.

 **Verifica la disponibilità delle risorse**:

```
# 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}'
```

 **Verifica le condizioni ReadyWhen (se utilizzate)**:

Il campo `readyWhen` è facoltativo. Se non specificato, le risorse sono considerate pronte immediatamente dopo la creazione. Se hai definito `readyWhen` delle condizioni, verifica che controllino correttamente la disponibilità delle risorse:

```
resources:
  - id: deployment
    readyWhen:
      - ${deployment.status.availableReplicas == deployment.spec.replicas}
```

 **Controlla gli eventi relativi alle risorse**:

```
# View events for the underlying resources
kubectl get events -n namespace --sort-by='.lastTimestamp'
```

## Errori di convalida dello schema
<a name="_schema_validation_failures"></a>

Se le istanze non vengono create a causa di errori di convalida dello schema, verifica che l'istanza soddisfi i requisiti dello schema RGD.

 **Controlla gli errori** di convalida:

```
# 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"
```

 Problemi di **convalida comuni**:
+  **Campi obbligatori mancanti**: l'istanza non fornisce tutti i campi dello schema obbligatori
+  **Mancata corrispondenza del tipo**: fornisce una stringa dove è previsto un numero intero
+  Valore **enum non valido: utilizzo di un valore** non presente nell'elenco consentito
+  **Mancata corrispondenza del modello**: la stringa non corrisponde al modello regex

 **Rivedi lo schema RGD**:

```
# View the schema definition
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.spec.schema}'
```

Assicurati che l'istanza fornisca tutti i campi obbligatori con i tipi corretti.

## Fasi successive
<a name="_next_steps"></a>
+  [considerazioni kro per EKS](kro-considerations.md)- considerazioni e best practice su kro
+  [Configura le autorizzazioni kro](kro-permissions.md)- Configura RBAC per i team di piattaforme e applicazioni
+  [concetti kro](kro-concepts.md)- Comprendi i concetti kro e il ciclo di vita delle risorse
+  [Risoluzione dei problemi delle funzionalità EKS](capabilities-troubleshooting.md)- Guida generale alla risoluzione dei problemi relativi alle funzionalità

# Confronto tra EKS Capability for kro e kro autogestito
<a name="kro-comparison"></a>

EKS Capability for kro offre le stesse funzionalità di kro autogestito, ma con vantaggi operativi significativi. Per un confronto generale tra EKS Capabilities e soluzioni autogestite, vedi. [Considerazioni sulle funzionalità EKS](capabilities-considerations.md)

EKS Capability for kro utilizza gli stessi controller kro upstream ed è completamente compatibile con upstream kro. ResourceGraphDefinitions, Le espressioni CEL e la composizione delle risorse funzionano in modo identico. Per la documentazione completa e gli esempi di kro, consulta la documentazione di [kro](https://kro.run/docs/overview).

## Percorso di migrazione
<a name="_migration_path"></a>

È possibile migrare da kro autogestito a funzionalità gestita senza tempi di inattività.

**Importante**  
Prima della migrazione, assicurati che il tuo controller kro autogestito utilizzi la stessa versione di EKS Capability for kro. Verifica la versione con funzionalità nella console EKS o in uso`aws eks describe-capability`, quindi aggiorna la tua installazione autogestita in modo che corrisponda. In questo modo si evitano problemi di compatibilità durante la migrazione.

1. Aggiorna il tuo controller kro autogestito da utilizzare per i contratti di locazione elettorali `kube-system` per i leader:

   ```
   helm upgrade --install kro \
     oci://ghcr.io/awslabs/kro/kro-chart \
     --namespace kro \
     --set leaderElection.namespace=kube-system
   ```

   Questo sposta il contratto di locazione del controllore`kube-system`, permettendo alla capacità gestita di coordinarsi con esso.

1. Crea la funzionalità kro sul tuo cluster (vedi) [Crea una funzionalità kro](create-kro-capability.md)

1. La funzionalità gestita riconosce le istanze esistenti ResourceGraphDefinitions e prende il sopravvento sulla riconciliazione

1. Ridimensiona gradualmente o rimuovi le implementazioni kro autogestite:

   ```
   helm uninstall kro --namespace kro
   ```

Questo approccio consente a entrambi i controller di coesistere in sicurezza durante la migrazione. La funzionalità gestita adotta ResourceGraphDefinitions automaticamente istanze precedentemente gestite da kro autogestito, garantendo una riconciliazione continua senza conflitti.

## Fasi successive
<a name="_next_steps"></a>
+  [Crea una funzionalità kro](create-kro-capability.md)- Crea una risorsa con funzionalità kro
+  [concetti kro](kro-concepts.md)- Comprendi i concetti kro e la composizione delle risorse