Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui la migrazione di Apigee hybrid a Helm da apigeectl

Questo strumento di migrazione consente di eseguire la migrazione di un cluster ibrido basato su apigeectl a un cluster ibrido basato su Helm. Questo strumento non esegue effettivamente la sostituzione di tutti i componenti del cluster. È idempotente e può essere eseguito in molti volte sullo stesso cluster, preparando un sottoinsieme di componenti e organizzazioni nel tempo.

Puoi eseguire la migrazione di tutti i componenti apigee contemporaneamente e Helm le operazioni di upgrade possono essere eseguite per singolo componente, dopo che lo strumento vengono eseguiti tutti i test delle unità.

Consulta Installare e gestire Apigee Hybrid con i grafici Helm per informazioni sulla gestione dei cluster ibride di cui hai eseguito la migrazione alla gestione Helm con questo strumento.

Prerequisiti

Versione Helm v3.14.2+.
Un file kubeconfig funzionante che rimanda a un cluster con un'installazione di Apigee hybrid 1.13 funzionante.
Autorizzazioni per modificare metadati e annotazioni in Kubernetes dei componenti ibridi di cui vuoi eseguire la migrazione.

Ambito

Questo strumento supporta le seguenti opzioni in fase di runtime:

Personalizzazione dello spazio dei nomi per le risorse apigee. Predefinita spazio dei nomi: apigee
Migrazione solo dei componenti ibridi selezionati. Predefinito: tutti i componenti vengono migrati
Migrazione di una sola organizzazione
Migrazione di un solo ambiente
Migrazione di un solo gruppo env (apigee-virtualhost)
Personalizzazione dei nomi delle release Helm per organizzazioni, envs e gruppi env.

Limitazioni

Questo strumento non supporta la personalizzazione dei nomi delle release di Helm per questi ibridi componenti: apigee-operator, apigee-datastore, apigee-redis, apigee-telemetry e apigee-ingress-manager.
Le personalizzazioni interattive apportate ai nomi delle release di Helm per organizzazioni, ambienti e gruppi di ambienti non vengono conservate automaticamente tra le esecuzioni. Puoi modificare temporaneo e fornitolo come opzione nelle esecuzioni successive.
I filtri Env e env-group vengono eseguiti solo per nome. In alcuni casi, questo potrebbe comportare la migrazione di più env e gruppi env su cluster di più organizzazioni.

Ad esempio, in un cluster multi-organizzazione con le organizzazioni org1 e org2, se l'ambiente prod è presente in entrambe e viene specificato solo --env=prod, verrà eseguita la migrazione di entrambi gli ambienti. Se vuoi eseguire la migrazione di una sola env, devi anche specificare un filtro per l'organizzazione --org=org1 o --org=org2.

Utilizzo

Sintassi

apigee-helm-migration [--apigee-namespace=] [--components=] [--dry-run] [--env=org1] [--env-group=org2] [--org=baz] [--kubeconfig=] [-y] [-v] [-f /path/to/releaseNames.yaml]

Nomi delle release di Helm generati

Ogni Helm Chart di cui viene eseguito il deployment in un cluster deve avere un nome release, che deve essere univoco all'interno di uno spazio dei nomi. I nomi delle release di Helm non hanno alcuna convenzione di denominazione o limitazione relativa al nome del grafico. Lo strumento di migrazione genera nomi di release Helm univoci per ogni componente.

Grafico	Cluster a organizzazione singola	Cluster multiorganizzazione
`apigee-operator`	`operator`	`operator`
`apigee-datastore`	`datastore`	`datastore`
`apigee-telemetry`	`telemetry`	`telemetry`
`apigee-redis`	`redis`	`redis`
`apigee-ingress-manager`	`ingress-manager`	`ingress-manager`
`apigee-org`	`ORG_NAME`	`ORG_NAME`
`apigee-env`	`ENV_NAME[-env[-n]]⁽¹⁾`	`ORG_NAME-ENV_NAME[-env[-n]]`⁽¹⁾
`apigee-virtualhost (envgroup)`	`VH_NAME[-env-group[-n]]`⁽¹⁾	`ORG_NAME-VH_NAME[-env-group[-n]]`⁽¹⁾
⁽¹⁾ I nomi hanno il suffisso `-env` o `-env-group` se il nome generato è in conflitto con un altro il nome generato. A questi viene aggiunto il suffisso `-1` o `-2 …` se il conflitto persiste.

Personalizzazione dei nomi delle release di Helm

Lo strumento di migrazione consente la personalizzazione interattiva dei nomi delle release di Helm. Se vuoi personalizzare i nomi delle release di Helm in modo non interattivo:

Esegui lo strumento una volta ed esci al primo prompt per creare un file temporaneo contenente i nomi delle release generate automaticamente. Dovresti vedere una riga simile a:
```
INFO: 21:32:56 using temp file for release names:  /tmp/apigee-helm-migration-1229129207-releaseNames
```
Sposta o copia e modifica questo file. Puoi passare questo file modificato con l'opzione -f quando esegui lo strumento di migrazione. I nomi delle release generati automaticamente sono:
```
orgs:
  example-apigee-org:
    helmReleaseName: example-apigee-org
    envs:
      prod:
        helmReleaseName: prod
    envGroups:
      prod-envgroup:
        helmReleaseName: prod-envgroup
```
Per personalizzare i nomi delle release Helm per un'organizzazione, un env o un envgroup, modifica il campo helmReleaseName dell'oggetto in questione. Ad esempio, per rinominare il rilascio dell'organizzazione in custom-org, il rilascio dell'ambiente in custom-env e il rilascio del gruppo di ambienti in custom-group, il file risultante sarà simile al seguente:
```
orgs:
  example-apigee-org:
    helmReleaseName: custom-org
    envs:
      prod:
        helmReleaseName: custom-env
    envGroups:
      prod-envgroup:
        helmReleaseName: custom-group
```

Utilizzo di spazi dei nomi personalizzati

Apigee hybrid versione 1.13 e successive viene eseguito in un unico spazio dei nomi Kubernetes. Tutti i componenti ibridi vengono eseguiti in questo nello spazio dei nomi. apigee è il nome predefinito. Per questi, puoi utilizzare qualsiasi spazio dei nomi personalizzato componenti.

Se utilizzi uno spazio dei nomi personalizzato, devi specificarlo con il flag --apigee-namespace my_custom_namespace quando esegui lo strumento di migrazione Helm.

Devi anche aggiungere la proprietà di primo livello namespace: my_custom_namespace al file degli override.

Istruzioni

Individua lo strumento di migrazione.

Lo strumento di migrazione è incluso nel pacchetto apigeectl in /tools/migration/.

Estrai i file compressi utilizzando uno dei seguenti comandi:

Mac:

tar -xzf apigee-helm-migration_1.0.2_mac_64.tar.gz

Linux:

tar -xzf apigee-helm-migration_1.0.2_linux_64.tar.gz

Windows:

tar -xzf apigee-helm-migration_1.0.2_windows_64.zip

Esegui lo strumento di migrazione. Se le opzioni predefinite sono accettabili, sufficiente per eseguire lo strumento senza argomenti e approvare il prompt se i nomi delle release Helm generati sono soddisfacenti. Di seguito sono riportati alcuni scenari di esempio:

Un'installazione semplice, che utilizza kubeconfig (~/.kube/config) predefinito, lo spazio dei nomi apigee predefinito e i nomi delle release di Helm predefiniti.

Il seguente comando dovrebbe essere sufficiente per la maggior parte dei casi, se non per tutti, per le installazioni di app. Le operazioni di upgrade di Helm possono essere eseguite per componente dopo l'esecuzione dello strumento.
```
./apigee-helm-migration
```
Esegui la migrazione di tutti i componenti utilizzando uno spazio dei nomi personalizzato:
```
./apigee-helm-migration --apigee-namespace my_custom_namespace
```

Esegui la migrazione solo dei componenti operator e datastore:

./apigee-helm-migration --components operator,datastore

  INFO: 00:22:48 using kubeconfig file  /usr/local/google/home/example/.kube/config
  INFO: 00:22:48 namespace for apigee resources:
  INFO: 00:22:48 	 apigee
  INFO: 00:22:48 processing all organizations in cluster
  INFO: 00:22:48 Components to migrate:
  INFO: 00:22:48 	 operator,datastore
  INFO: 00:22:48 dry-run:
  INFO: 00:22:48 	 false
  Continue with patching apigee resources for Helm migration? [y/n]: y
  INFO: 00:22:52 Processing component:  operator
  INFO: 00:22:54 Processing component:  datastore
  INFO: 00:22:55 Migration successful!

Puntare a un file kubeconfig specifico e specificare una un nome diverso per lo spazio dei nomi apigee.
```
./apigee-helm-migration --kubeconfig /abs/path/to/kubeconf --namespace org1_namespace
```
Esegui la migrazione di tutti i componenti, ma di una sola organizzazione:
```
./apigee-helm-migration --org=some-test-org
```

Di seguito è riportato un output di esempio da una migrazione riuscita:

INFO: 21:32:55 using kubeconfig file  /usr/local/google/home/example/.kube/config
INFO: 21:32:55 namespace for apigee resources:
INFO: 21:32:55 	 apigee
INFO: 21:32:55 processing all organizations in cluster
INFO: 21:32:55 processing all components
INFO: 21:32:55 dry-run:
INFO: 21:32:55 	 false
INFO: 21:32:55 cluster Apigee information:
INFO: 21:32:55 Apigee Organizations found:
INFO: 21:32:56 	 example-hybrid-dev
INFO: 21:32:56 Apigee Environments found (org: env):
INFO: 21:32:56 	 example-hybrid-dev : prod
INFO: 21:32:56 Apigee EnvGroups(apigeerouteconfigs) found (org: envGroup):
INFO: 21:32:56 	 example-hybrid-dev : prod-envgroup
INFO: 21:32:56 using temp file for release names:  /tmp/apigee-helm-migration-1229129207-releaseNames
INFO: 21:32:56 Helm release names for Apigee orgs/envs/envgroups:
orgs:
example-hybrid-dev:
helmReleaseName: example-hybrid-dev
envs:
  prod:
    helmReleaseName: prod
envGroups:
  prod-envgroup:
    helmReleaseName: prod-envgroup
Make changes to the release names for Apigee orgs/env/envgroups? [y/n]: n
Continue with patching apigee resources for Helm migration? [y/n]: y
INFO: 21:32:59 Processing component:  operator
INFO: 21:33:01 Processing component:  datastore
INFO: 21:33:01 Processing component:  redis
INFO: 21:33:02 Processing component:  ingress-manager
INFO: 21:33:02 Processing component:  telemetry
INFO: 21:33:03 Processing component:  orgs
INFO: 21:33:05 Processing component:  envs
INFO: 21:33:06 Processing component:  env-groups
INFO: 21:33:07 Migration successful!

Potenziali errori:

Errore durante l'analisi del file dei nomi delle release: controlla il passato dei nomi delle release.
Risorse non trovate: verifica che Apigee hybrid sia completamente installato e di disporre delle autorizzazioni per accedere alle risorse apigee.

Modifiche alle proprietà di configurazione

Apporta le seguenti modifiche ai file di override:

Apigee ibrido gestito con Helm utilizza le proprietà apigeeIngressGateway per configurare tutti i gateway Apigee in entrata nel tuo cluster. Le proprietà ingressGateways sostituiscono le impostazioni in apigeeIngressGateway per il singolo gateway di ingresso denominato.
Leggi apigeeIngressGateway
- Modifica le proprietà ingressGateways globali per tutti i gateway di ingresso del cluster in proprietà apigeeIngressGateway. Il file delle sostituzioni deve contenere almeno:
```
apigeeIngressGateway:
  image:
    url: "PATH_TO_REPOSITORY/apigee-asm-ingress"
    tag: "TAG"
```
  Ad esempio:
```
apigeeIngressGateway:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
    tag: "1.17.8-asm.20-distroless"
```
- Assicurati di includere ingressGateways.name. È necessario per l'inizializzazione del gateway di ingresso. Ad esempio:
Le proprietà per abilitare Workload Identity sono state modificate:
- gcp.workloadIdentity.enabled sostituisce gcp.workloadIdentityEnabled.
- Se utilizzi un unico account di servizio per tutti i componenti, puoi specificarlo con: gcp.workloadIdentity.gsa. Ad esempio:
```
gcp:
  workloadIdentity:
    enabled: true
    gsa: "apigee-non-prod@my-hybrid-project.iam.gserviceaccount.com"
```
- Se utilizzi un account di servizio separato per ogni componente (lo standard per la maggior parte delle installazioni di produzione), specifica l'account di servizio con la proprietà gsa del componente. Ad esempio:
```
logger:
  gsa: "apigee-logger@my-hybrid-project.iam.gserviceaccount.com"
```
Consulta: gcp.workloadIdentity.enabled, gcp.federatedWorkloadIdentity.enabled, Abilitazione di Workload Identity su GKE o Attivazione della federazione delle identità per i carichi di lavoro su AKS ed EKS.

Risoluzione dei problemi

Nella release ibrida v1.12 esiste un problema noto con lo strumento di migrazione di Helm. Fino a quando il problema non sarà risolto, Cassandra backup and restore richiede passaggi aggiuntivi.

Puoi procedere nel seguente modo:

Prima o dopo l'esecuzione dello strumento di migrazione
Prima di installare i grafici Helm

Per installare la patch per la soluzione alternativa:

Assicurati che il tuo kubeconfig attuale indichi il cluster di cui vuoi eseguire la migrazione. Puoi eseguire questi passaggi da qualsiasi directory.

Crea un file denominato migration-operator-patch.yaml con i seguenti contenuti:

# migration-operator-patch.yaml
metadata:
  annotations:
    meta.helm.sh/release-name: operator
    meta.helm.sh/release-namespace: APIGEE_NAMESPACE
  labels:
    app.kubernetes.io/managed-by: Helm

Crea un file denominato migration-datastore-patch.yaml con i seguenti contenuti:

# migration-datastore-patch.yaml
metadata:
  annotations:
    meta.helm.sh/release-name: datastore
    meta.helm.sh/release-namespace: apigee
  labels:
    app.kubernetes.io/managed-by: Helm

Esegui i seguenti comandi kubectl:

kubectl patch clusterrole apigee-cassandra-backup --patch-file ./migration-operator-patch.yaml
kubectl patch clusterrole apigee-cassandra-restore --patch-file ./migration-operator-patch.yaml
kubectl patch clusterrolebinding apigee-cassandra-backup --patch-file ./migration-operator-patch.yaml
kubectl patch clusterrolebinding apigee-cassandra-restore --patch-file ./migration-operator-patch.yaml
kubectl patch -n APIGEE_NAMESPACE cronjob apigee-cassandra-backup --patch-file ./migration-datastore-patch.yaml
kubectl patch -n APIGEE_NAMESPACE certificate apigee-cassandra-backup-tls --patch-file ./migration-datastore-patch.yaml --type merge
kubectl patch -n APIGEE_NAMESPACE secret apigee-cassandra-backup-svc-account --patch-file ./migration-datastore-patch.yaml
kubectl patch -n APIGEE_NAMESPACE secret apigee-cassandra-backup-key-file --patch-file ./migration-datastore-patch.yaml
kubectl patch -n APIGEE_NAMESPACE ServiceAccount apigee-cassandra-backup-sa --patch-file ./migration-datastore-patch.yaml
kubectl patch -n APIGEE_NAMESPACE job apigee-cassandra-restore --patch-file ./migration-datastore-patch.yaml
kubectl patch -n APIGEE_NAMESPACE certificate apigee-cassandra-restore-tls --patch-file ./migration-datastore-patch.yaml --type merge
kubectl patch -n APIGEE_NAMESPACE secret apigee-cassandra-restore-svc-account --patch-file ./migration-datastore-patch.yaml
kubectl patch -n APIGEE_NAMESPACE secret apigee-cassandra-restore-key-file --patch-file ./migration-datastore-patch.yaml
kubectl patch -n APIGEE_NAMESPACE ServiceAccount apigee-cassandra-restore-sa --patch-file ./migration-datastore-patch.yaml

Nota: puoi ignorare gli errori not found.

Pulisci i file patch utilizzando i seguenti comandi:

rm migration-operator-patch.yaml
rm migration-datastore-patch.yaml

Passaggio successivo

Continua l'installazione dei grafici Helm ibridi Apigee con le istruzioni in Installazione e gestione di Apigee hybrid con i grafici Helm.

Importante: quando segui le istruzioni per il cluster sottoposto a migrazione, devi omettere il flag ‑‑atomic da tutti i comandi Helm per evitare di eliminare accidentalmente le risorse se il comando helm upgrade non va a buon fine.

Output di -help

./apigee-helm-migration --help

Usage of ./apigee-helm-migration:
  -apigee-namespace string
      namespace used for apigee resources (default "apigee")
  -components string
      CSV of components to migrate. If empty then all components are migrated. Valid values are: operator,datastore,redis,ingress-manager,telemetry,orgs,envs,env-groups
  -dry-run
      perform a dry-run
  -env string
      restrict migration to a singular supplied env. If empty then all envs detected in the cluster are migrated
  -env-group string
      restrict migration to a singular supplied envGroup. If empty then all envGroups detected in the cluster are migrated
  -kubeconfig string
      (optional) absolute path to the kubeconfig file (default "/usr/local/google/home/example/.kube/config")
  -org string
      restrict migration to a singular supplied org. If empty then all orgs detected in the cluster are migrated
  -v	Increased logging verbosity
  -y	don't prompt for confirmation or for configuration of Helm releases