Anteprima dell'installazione e dell'amministrazione del nuovo Apigee hybrid

Questa anteprima è stata interrotta.

Anteprima — Nuovo processo di installazione di Apigee hybrid (non più attivo)

Questa funzionalità è soggetta ai "Termini dell'offerta pre-GA" nella sezione dei Termini di servizio generali dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

---

Anteprima della guida utente:
Anteprima delle nuove procedure di installazione e amministrazione per Apigee hybrid v1.8.

---

In questo documento:

• Anteprima
  • Feedback
• Panoramica
  • Modifiche al nuovo processo di installazione
• Prerequisiti
  • Versione di anteprima
  • Configurazione ibrida Apigee
  • Strumenti
• Installazione base di Apigee Hybrid
  • Scarica i file di installazione
  • Esegui setup
• Installazione ibrida Apigee personalizzata
  • Scarica i file di installazione
  • Crea spazio dei nomi
  • Utilizzo di immagini Docker da repository privati (facoltativo)
  • Configurazione di imagePullSecrets (facoltativo)
  • Configurazione del proxy in avanti (facoltativo)
  • Specificare i certificati TLS in ingresso
  • Aggiorna la distribuzione in entrata
  • Configurazione di account di servizio Google Cloud personalizzati
  • Utilizzo delle identità del carico di lavoro
  • Modifica i file YAML delle risorse
  • Crea le risorse di inizializzazione e il controller
  • Concedere le autorizzazioni all'account del servizio Synchronizer per interagire con il Control Plane
  • Crea i componenti del piano dati di Apigee
  • Attendi l'avvio delle risorse
  • Personalizza l'installazione di cert-manager in uno spazio dei nomi personalizzato
• Personalizza e componenti
  • Panoramica
  • Come utilizzare i componenti
  • OpenShift
  • imagepullsecret
  • nodeselector
  • identità-carico-di-lavoro
  • http-proxy
  • logger e metriche
  • gcs-backup e gcs-restore
  • non-gcs-backup e non-gcs-restore
  • http-client
  • client non-sni
  • http-and-non-sni-client
  • multi-region
• Concetti
  • Aggiunta di un nuovo ambiente
  • Utilizzo dell'eliminazione forzata in Apigee Datastore
• Comprendere la sceneggiatura
• Struttura delle cartelle di configurazione di Apigee Hybrid
• Archiviazione delle chiavi dell'account di servizio in vault esterni
• Aggiornamento ibrido Apigee
  • Crea backup
  • Aggiorna la tua piattaforma Kubernetes se necessario
  • Scarica i file di installazione
  • Aggiorna le autorizzazioni dell'account di servizio se necessario
  • Aggiorna il controller
  • Aggiorna i componenti di Apigee Kubernetes
• Apigee Hybrid Rollback
  • Ripristina la configurazione ibrida di apigee
  • Esegui il rollback dei componenti di Kubernetes
  • Controller di rollback
• Pulizia
• Eliminazione di un ambiente
  • Eliminazione di una configurazione ibrida
• Installazione di più istanze
  • Configurazione multi-istanza su GKE
  • Risoluzione dei problemi
  • Guida alla compatibilità, alla diagnosi e alla risoluzione dei problemi
  • Pulizia manuale dopo l'utilizzo di forceDelete nella configurazione ibrida di Apigee multiregionale

Anteprima

---

Nota: Questo documento e il software che documenta fanno parte di una versione di anteprima. Apigee non fornisce alcuna garanzia sul software o sulle procedure presentate in questa anteprima. La documentazione e il software sono soggetti a modifiche senza preavviso.

Questo documento è destinato al profilo operatore di Apigee (utenti che installano, gestiscono e amministrano le installazioni di Apigee hybrid). L'esperienza nell'installazione di Apigee hybrid su una delle piattaforme Kubernetes supportate è un prerequisito per seguire le istruzioni riportate in questo documento. Si consiglia di creare un'organizzazione Apigee di valutazione per provare i passaggi descritti di seguito.

Feedback

Si prega di inviare un feedback su questo processo a [e-mail].

---

Panoramica

La nuova esperienza di installazione ibrida di Apigee installa i componenti di Apigee utilizzando kubectl e integra l'installazione e la gestione di Apigee Hybrid con strumenti di orchestrazione della configurazione di Kubernetes come Kustomize. Le convalide e la visibilità migliorate dei componenti in fase di installazione offrono una migliore capacità di debug e migliorano il processo di installazione complessivo.

Uno script di installazione, apigee-hybrid-setup.sh, fornisce uno strumento semplice per l'installazione di base. Puoi utilizzarlo per creare l'installazione ibrida e poi modificarla in base alle tue esigenze con kubectl oppure puoi creare l'installazione ibrida da zero utilizzando kubectl. Tutte le proprietà di configurazione di Apigee hybrid sono archiviate in file YAML, uno per ogni componente principale. Ciò consente un controllo molto più granulare dell'installazione ibrida nell'ambiente Kubernetes. Puoi trovare i file di configurazione e gli script di installazione nel repository su GitHub.

Modifiche alla nuova procedura di installazione

Apigee sta modificando la procedura di installazione di Apigee Hybrid per i seguenti motivi:

• Il nuovo metodo di installazione di Apigee hybrid può essere integrato con strumenti CI/CD Kubernetes esistenti come Argo, Flux o Anthos Config Management che non utilizzano unoverrides.yaml file di configurazione.
• Apigee hybrid ha fornito apigeectl, uno strumento di modelli personalizzato che genera manifest Kubernetes (tra le altre cose) per installare e gestire Apigee hybrid nei cluster Kubernetes. Il nuovo processo di installazione e gestione offre un'esperienza simile a quella di altri fornitori di software.
• Il nuovo processo consente un'installazione di base rapida, creando automaticamente account di servizio con le autorizzazioni necessarie, certificati TLS, precompilando i valori predefiniti e altri elementi fondamentali.

Prerequisiti

Prima di utilizzare questa installazione di anteprima, devi soddisfare i seguenti prerequisiti:

Versione di anteprima

Questa anteprima è pensata per funzionare con Apigee hybrid versione 1.8.x. Le versioni successive di Apigee Hybrid non sono supportate.

Configurazione di Apigee hybrid

Prima di procedere con l'installazione effettiva di Apigee Hybrid, devi aver completato le seguenti istruzioni elencate nelle sezioni successive della documentazione:

1. Configurazione di progetto e organizzazione
   • Panoramica per i prerequisiti per l'installazione di Apigee hybrid.
   • Passaggio 1: attiva le API
   • Passaggio 2: Creare un'organizzazione
   • Passaggio 3: crea un ambiente e un gruppo di ambienti
2. Configurazione del runtime di hybrid
   • Passaggio 1: crea un cluster
   • Passaggio 2: installa cert-manager

Strumenti

Inoltre, devi scaricare e configurare i seguenti strumenti sulla workstation:

• curl
• docker è necessario per eseguire lo script apigee-hybrid-setup.sh. Segui le istruzioni su Ottieni Docker per installare Docker.
• envsubst dovrebbe essere disponibile nella maggior parte dei sistemi basati su Linux/UNIX. Per MacOS e altri sistemi, seguire le istruzioni in questo repository.
• jq deve essere installato. Scarica jq.

• kpt Scarica kpt.

  Nota: le versioni di KPT v0.39 e precedenti non sono supportate. Scarica kpt dal link sopra indicato (v1.0+) per assicurarti che funzioni.

• kubectl versione 1.23 o successiva. Vedi Installa strumenti: kubectl nella documentazione di Kubernetes.

Variabili comuni utilizzate in questa guida

Questa guida utilizza le seguenti variabili d'ambiente in diverse fasi. È possibile definirli tramite riga di comando o con uno script, oppure è possibile sostituire il testo nei comandi al momento dell'inserimento.

• APIGEE_NAMESPACE: Il tuo namespace Apigee. Per impostazione predefinita, questo valore è apigee. Tuttavia, è possibile utilizzare uno spazio dei nomi diverso.
• CLUSTER_NAME: Il nome del cluster in cui stai installando Apigee Hybrid. Questo è il cluster che crei nel Passaggio 1: Crea un cluster
• CLUSTER_LOCATION: la regione del cluster. Le procedure descritte in questa guida presuppongono l'utilizzo di un cluster regionale. Se utilizzi un cluster di zona, consulta le istruzioni riportate nel passaggio 1: crea un cluster.
• ENV_GROUP: il nome del gruppo di ambienti per l'installazione di Apigee hybrid. Questo è il gruppo di ambienti che crei nel passaggio 3: crea un gruppo di ambienti. È possibile creare più gruppi di ambienti.
• ENV_NAME: il nome del gruppo di ambienti per l'installazione di Apigee hybrid. Questo è il gruppo di ambienti che crei nel Passaggio 3: Crea un gruppo di ambienti. È possibile creare più gruppi di ambienti.
• INSTALL_DIR: La directory in cui installi Apigee Hybrid. Per impostazione predefinita, si tratta della sottocartella apigee-hybrid-install/ della directory in cui si scarica il programma di installazione, ad esempio: /myhybrid/apigee-hybrid-install/. Questa è la directory radice per la struttura dei file documentata in Struttura delle cartelle di configurazione ibrida di Apigee.
• INSTANCE_DIR: La directory per una specifica istanza ibrida di Apigee. Per impostazione predefinita, la prima istanza viene denominata instance-1. La directory dell'istanza è una sottodirectory di ${INSTALL_DIR}/overlays/instances/. È possibile specificare un nome qualsiasi per le istanze ibride. Vedi Installazione multi-istanza.
• ORG_NAME: Il nome della tua organizzazione ibrida Apigee. Deve corrispondere all'ID del tuo progetto Google Cloud. Vedi: Passaggio 2: Crea un'organizzazione.

Installazione base di Apigee hybrid

Per installare rapidamente Apigee Hybrid senza personalizzazioni complesse, puoi utilizzare la seguente procedura in due passaggi.

---

Nota: Un'installazione di base ha la seguente configurazione:

• Un ambiente unico
• Un singolo gruppo di ambienti
• Viene creato e utilizzato un unico account di servizio Google Cloud per tutti i singoli componenti
• Valori predefiniti per tutte le chiavi di crittografia e le password.

---

1. Scarica i file di installazione
2. Esegui configurazione

Scarica i file di installazione

Scarica e prepara i file di installazione clonando il repository GitHub all'indirizzo https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1:

1. Clona il repository:

   git clone https://github.com/apigee/apigee-hybrid-install.git
   

2. Accedere alla directory del repository clonato:

   cd apigee-hybrid-install
   

3. Crea un branch dal tag preview-1:

   git branch preview-1 preview-1
   git checkout preview-1
   

4. Rendi eseguibile lo script di configurazione:

   chmod +x ./tools/apigee-hybrid-setup.sh
   

   Il repository clonato avrà una struttura simile a quella descritta in Struttura delle cartelle di configurazione di Apigee Hybrid:

Esecuzione configurazione

Eseguire ilapigee-hybrid-setup.sh script shell situato all'internotools/ cartella.

./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION --org $ORG_NAME --setup-all

---

Nota: l'esecuzione dello script con questi argomenti utilizza l'organizzazione, l'ambiente e il gruppo di ambienti Apigee che hai creato in Prerequisiti.

Se riscontri degli errori, prova a eseguire lo script una seconda volta.

---

Altre opzioni che potresti voler utilizzare sono:

• --env $ENV_NAME specifica il nome dell'ambiente Apigee.
• --envgroup $ENV_GROUP specifica il gruppo di ambienti.
• --ingress-domain $HOSTNAME specifica il nome host fornito per il gruppo di ambienti.
• --gcp-project-id $PROJECT_ID specifica l'ID del tuo progetto Google Cloud.

Per ulteriori opzioni, consulta Informazioni sullo script.

Eventuali errori durante l'esecuzione verranno stampati sull'output standard.

Una volta che lo script sarà stato eseguito correttamente, avrai completato l'installazione ibrida di base. È possibile testare l'installazione creando un proxy di esempio come descritto in Creare e distribuire un nuovo proxy API.

Installazione personalizzata di Apigee Hybrid

Per gli utenti più esperti che desiderano un controllo più preciso sull'installazione, è possibile seguire questa sequenza di passaggi (per molti dei passaggi indicati di seguito, è possibile scegliere se eseguirli manualmente o utilizzare lo script shell per automatizzare il singolo passaggio):

---

Nota: Questi passaggi richiedono una conoscenza di base dei concetti di Kubernetes. Fare riferimento alla sezione Concetti oDocumentazione di Kubernetes per maggiori dettagli.

---

Scarica i file di installazione

Scarica e prepara i file di installazione:

1. Clona il repository GitHub all'indirizzo https://github.com/apigee/apigee-hybrid-install/

   Il repository clonato avrà una struttura simile a quella descritta in Struttura delle cartelle di configurazione di Apigee Hybrid:

2. cdnelapigee-hybrid-install/ licenza

3. Rendi eseguibile lo script di configurazione:

   chmod +x ./tools/apigee-hybrid-setup.sh
   

Crea spazio dei nomi

Crea uno spazio dei nomi Kubernetes nel tuo cluster che conterrà tutti i componenti del cluster Apigee.

kubectl create namespace apigee

---

Nota: Apigee è il nome predefinito per lo spazio dei nomi. Puoi usare un nome diverso.

---

Se si sceglie un nome diverso per lo spazio dei nomi, è possibile seguire una delle tre opzioni seguenti:

• (Consigliato) Utilizzare --namespace={YOUR_NAMESPACE_NAME} durante il precompilazione dei valori in Modifica risorse yaml.

• Eseguire i due comandi seguenti:

  1. Utilizzare kpt per specificare lo spazio dei nomi Apigee:

     kpt fn eval "${INSTALL_DIR}/overlays/" \
       --image gcr.io/kpt-fn/apply-setters:v0.2.0 -- \
       APIGEE_NAMESPACE="${APIGEE_NAMESPACE}"
     # This is for replacing the namespace in istio discoveryAddress which cannot be
     # achieved with kpt
     

  2. Utilizzare sed per sostituire il namespace in istio discoveryAddress:

     sed -i -E -e "s/(discoveryAddress: apigee-ingressgateway-manager\.).*(\.svc:15012)/\1${APIGEE_NAMESPACE}\2/" "${INSTALL_DIR}/overlays/controllers/istiod/apigee-istio-mesh-config.yaml"
     

• In alternativa, è possibile modificare manualmente le risorse singolarmente affinché vengano create nello spazio dei nomi desiderato.

Utilizzo di immagini Docker da repository privati ​​ (facoltativo)

È possibile scegliere di non utilizzare le immagini ospitate pubblicamente e di utilizzare immagini provenienti dai propri repository privati:

1. Il primo passo è caricare tutte le immagini nel tuo repository privato, operazione che può essere eseguita seguendo i passaggi descritti in apigee-pull-push | Apigee X. Per impostazione predefinita, le immagini vengono etichettate con la versione di Apigee Hybrid corrispondente e si consiglia di non modificare queste etichette. Si consiglia inoltre di non modificare i nomi delle immagini, in modo che il percorso finale dell'immagine possa essere costruito come spiegato in Image Hub.

2. Imposta il valore del campo imageHub presente nel file apigee-hybrid-config.yaml sul percorso host del repository privato. (Per i dettagli, consultare Image Hub).

   imageHub: "your.private.repo/apigee/hybrid"
   

In questo modo, tutti i componenti Apigee hybrid utilizzeranno le immagini presenti nel tuo repository privato.

Oltre a ciò, potresti anche voler utilizzare un'immagine privata per il controller e il gateway di ingresso Apigee, per cui dovrai modificare i file apigee-controller-deployment.yaml e apigee-ingressgateway-manager-deployment.yaml e sostituire tutti i campi image ​​con l'immagine dal loro repository privato.

---

Nota: Se stai scaricando immagini da un repository privato, molto probabilmente dovrai autenticarti per poterle scaricare. Le credenziali richieste per questa autenticazione sono specificate come imagePullSecrets, che è stato discusso in dettaglio in Configurazione di imagePullSecrets (facoltativo).

---

Configurazione di imagePullSecrets (facoltativa)

1. Crea un segreto di kubernetes contenente le credenziali per autenticarsi con i repository privati. Consulta Estrarre un'immagine da un registro privato per capire come deve essere creato il segreto.
2. Una volta creato il segreto, non resta che farvi riferimento, operazione che può essere eseguita modificando il file apigee-hybrid-config.yaml e impostando il valore del campo imagePullSecret sul nome del segreto creato in precedenza, e abilitando il componente imagePullSecret nel corrispondente file kustomization.yaml.

---

Nota: Se stai utilizzando immagini private per ilcontroller anche, quindi potrebbe essere necessario aggiungere ancheimagePullSecret campi s nella specifica di distribuzione presente nelapigee-controller-deployment.yaml Eapigee-ingressgateway-manager-deployment.yaml file.

Se si specifica imagePullSecrets in entrambi i punti, prevarrà quello presente nel file apigee-controller-manager.yaml.

---

Configurazione del proxy in avanti (facoltativa)

È possibile configurare i proxy forward aggiungendo il campo forwardProxy al file apigee-hybrid-config.yaml. Ad esempio:

  forwardProxy: |
    scheme: HTTP
    host: 10.12.0.47
    port: 3128

Specificare i certificati TLS in ingresso

Utilizzando lo script

./tools/apigee-hybrid-setup.sh --create-ingress-tls-certs

Consultare la sezione Comprensione dello script per maggiori dettagli su questo flag.

Manuale

Devi fornire i certificati TLS che verranno utilizzati per il gateway in entrata Istio. Puoi:

• oppure utilizzare certificati firmati da un'autorità nota seguendo i passaggi menzionati in Ottenere certificati TLS: un esempio | Apigee X
• o generare certificati autofirmati.

In questo caso useremo come esempio i certificati autofirmati. È possibile generare certificati autofirmati utilizzando (supponendo che DOMAIN sia stato impostato correttamente e che corrisponda al nome host impostato nel gruppo di variabili d'ambiente):

openssl req -nodes -new -x509 -keyout ./tls.key -out ./tls.crt -subj '/CN='$DOMAIN'' -days 3650

Questo creerà due file denominati tls.key e tls.crt.

È quindi necessario creare un segreto avente il seguente formato. È possibile utilizzare kubectl create o kubectl apply come spiegato in Utilizzo di una coppia certificato/chiave personalizzata per l'autorità di firma del certificato (facoltativo):

apiVersion: v1
kind: Secret
metadata:
  name: "{ORG_NAME}-{ENV_GROUP_NAME}"
  namespace: {$APIGEE_NAMESPACE}
type: Opaque
data:
  cert: |
    {BASE64_ENCODED_TLS_CRT}
  key: |
    {BASE64_ENCODED_TLS_KEY}

---

Esempio di creazione del segreto utilizzando kubectl create:

kubectl create secret tls {ORG_NAME}-{ENV_GROUP_NAME} \
  --cert="tls.crt" \
  --key="tls.key" \
  -n {$APIGEE_NAMESPACE}

---

Nota: Se modifichi il nome del segreto sopra, dovrai apportare una modifica corrispondente inapigee-route-config.yaml modificando il valore disecretNameRef AYOUR_SECRET_NAME

---

Aggiornare la distribuzione in entrata

Per creare/modificare le distribuzioni ingress, è necessario modificare il campo spec.components.ingressGateways nella risorsa personalizzata ApigeeOrganization in bases/initialization/crds/customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml.

Per impostazione predefinita, creiamo una distribuzione ingress con parametri predefiniti(i valori predefiniti saranno mostrati nella documentazione di riferimento CR ):

ingressGateways:
- name: "prod-1"

Esempi:

A. Sovrascrivere i campi del servizio di ingresso

ingressGateways:
- name: "prod-1"
  serviceSpec:
    annotations:
      {KEY}: ${VALUE}
    loadBalancerIP: ${IP}

B. Modifica replica Min/Max

ingressGateways:
- name: "prod-1"
  ​​autoScaler:
    minReplicas: 4
    maxReplicas: 10

C. Aggiunta di una nuova distribuzione Ingress

ingressGateways:
- name: "prod-1"
- name: "prod-2"

Configurazione di account di servizio Google Cloud personalizzati

---

Nota: è obbligatorio configurare service account Google Cloud personalizzati o utilizzare identità del workload)

---

Utilizzando lo script

./tools/apigee-hybrid-setup.sh --create-gcp-sa-and-secrets  --namespace APIGEE_NAMESPACE

Dove APIGEE_NAMESPACE è il tuo namespace personalizzato. Lo spazio dei nomi predefinito è apigee.

Per maggiori dettagli sui flag, consultare Comprendere lo script.

Manuale

Le chiavi dell'account di servizio di Google Cloud devono essere archiviate come segreti nel cluster. Il file YAML segreto dovrebbe avere la seguente struttura:

apiVersion: v1
kind: Secret
metadata:
  name: "{NAME}"
  namespace: {APIGEE_NAMESPACE}
type: Opaque
data:
  client_secret.json: |
    {BASE64_ENCODED_SA_KEY}

Per maggiori dettagli su quali account di servizio sono necessari e sui nomi dei segreti, consultare la sezione Account di servizio di Google Cloud.

Siete liberi di scegliere un nome diverso per i segreti, ma in tal caso dovrete apportare la modifica corrispondente nel componente in cui è stato utilizzato quel nome. Ad esempio, se si decide di modificare il nome del segreto dell'account di servizio runtime daapigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME} Amy-runtime-svc, dovrai apportare una modifica corrispondente nelapigee-environment.yaml per quell'ambiente

---

Nota: I segreti che contengono le chiavi dell'account di servizio possono essere reperiti da strumenti esterni di gestione dei segreti come Vault. Consultare la sezione Archiviazione delle chiavi dell'account di servizio in vault esterni per i dettagli su come procedere.

---

Utilizzo delle identità del carico di lavoro

---

Nota: Le identità dei carichi di lavoro possono essere utilizzate solo con i cluster GKE in Google Cloud.

È obbligatorio configurare un account di servizio Google Cloud personalizzato oppure utilizzare le identità dei carichi di lavoro.

---

Prerequisiti

Prima di utilizzare le identità di carico di lavoro, assicurati che il tuo cluster GKE abbia il supporto abilitato. Consultare Aggiornamento dei pool di nodi | Apigee X per i dettagli.

Abilitazione dell'identità del carico di lavoro

Consulta la sezione Identità del carico di lavoro in Personalizza e componenti per i dettagli su come abilitare le identità del carico di lavoro prima dell'installazione.

Modifica i file YAML delle risorse

Alcuni punti dei file YAML dei componenti richiedono la presenza dei nomi corretti di organizzazione, ambiente e gruppo di ambienti. Puoi impostare questi valori manualmente o utilizzare lo script shell per compilarli automaticamente.

Utilizzo dello script

./tools/apigee-hybrid-setup.sh --fill-values

Creazione delle risorse di inizializzazione e del controller

#Additional steps for openshift
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/openshift
//apigee datastore
kubectl apply -f ${INSTANCE_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/components/openshift-scc/scc.yaml
//telemetry
kubectl apply -f ${INSTANCE_DIR}/overlays/instances/${INSTANCE_DIR}/telemetry/components/openshift-scc/scc.yaml

#Create Apigee initialization kubernetes resources
kubectl apply -f ${INSTALL_DIR}/overlays/initialization/namespace.yaml
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/certificates
kubectl apply --server-side --force-conflicts -k ${INSTALL_DIR}/overlays/initialization/crds
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/webhooks
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/rbac
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/ingress

# Create controller config and controller
kubectl apply -k ${INSTALL_DIR}/overlays/controllers

# Wait for the controllers to be available
kubectl wait deployment/apigee-controller-manager deployment/apigee-ingressgateway-manager -n "${APIGEE_NAMESPACE}" --for=condition=available --timeout=2m

# Create the datastore and redis secrets first and then the rest of the secrets.
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/redis/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/${ENV_NAME}/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/organization/secrets.yaml

Concedere le autorizzazioni all'account di servizio Synchronizer per interagire con il Control Plane.

Segui i passaggi in Passaggio 8: Abilita l'accesso al sincronizzatore, sostituendo il nome dell'account di servizio, sia apigee-non-prod che apigee-synchronizer, con apigee-all-sa, il nome dell'account di servizio creato dal nuovo processo di installazione.

---

★ Importante: Assicurati di modificare il nome del account di servizio nelle istruzioni sotto Abilita l'accesso al sincronizzatore. Altrimenti, l'abilitazione dell'accesso per il sincronizzatore non andrà a buon fine.

---

Creare i componenti del piano dati di Apigee

Se hai modificato i nomi di una delle risorse nei passaggi precedenti, dovrai apportare una modifica corrispondente in altri file YAML in cui è stata fatto riferimento a quella risorsa. Una volta fatto, utilizza i comandi nell'esempio seguente:

# Create the rest of the resources.
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}

per installare tutti i componenti.

Attendi l'avvio delle risorse

kubectl wait "apigeedatastore/default" \
"apigeeredis/default" \
"apigeeenvironment/${ORG_NAME}-${ENV_NAME}" \
"apigeeorganization/${ORG_NAME}" \
"apigeetelemetry/apigee-telemetry" \
-n "${APIGEE_NAMESPACE}" --for="jsonpath=.status.state=running" --timeout=15m

Personalizzare l'installazione di cert-manager in uno spazio dei nomi personalizzato

Personalizza lo spazio dei nomi in cui è in esecuzione cert-manager seguendo la procedura descritta di seguito.

Se cert-manager è installato nel cluster in un namespace diverso da cert-manager, sarà necessario aggiornare il namespace utilizzato per creare il certificato radice di Apigee.

1. Modifica il file customization.yaml per la creazione del certificato: $INSTALL_DIR/overlays/initialization/certificates/kustomize.yaml

2. Aggiungi quanto segue alla fine del file.

   - patch: |-
   - op: replace
     path: /metadata/namespace
     value: "gk-cert-manager"
   target:
   group: cert-manager.io
   version: v1
   kind: Certificate
   name: apigee-root-certificate
   

3. Salva il file.

Personalizza e componenti

Panoramica

La nuova installazione ibrida eredita l'ideologia Kustomize di strutturazione degli yaml sotto forma di Basi e Sovrapposizioni

• Le basi sono file forniti da Apigee, che potrebbero cambiare tra una nuova versione di Hybrid e l'altra. Non è previsto che tu modifichi questi file. Questi file contengono alcuni valori predefiniti forniti da Apigee. Tutti i file nella cartella di primo livello bases/ contengono queste basi

• Gli overlay contengono la configurazione utente e fungono da mezzo attraverso il quale è possibile modificare i valori predefiniti specificati nelle basi. Tutti i file nella cartella di primo livello overlays/ contengono queste sovrapposizioni

  ---

  Nota: Per una migliore comprensione di Kustomize e di come le sovrapposizioni sono state utilizzate per modificare le basi, si consiglia vivamente di consultarePersonalizza le toppe.

  ---

Come utilizzare i componenti

Le sottocartelle all'interno della directory di livello superiore overlays/ sono state strutturate in modo tale da consentire l'attivazione (o la disattivazione) di una determinata funzionalità aggiuntiva commentando (o decommentando) alcune righe nei file kustomization.yaml.

Ad esempio, ecco come si presenta la struttura delle cartelle overlays/instances/{INSTANCE_NAME}/telemetry:

telemetry
├── components
│   ├── http-proxy
│   ├── imagepullsecret
│   ├── logger
│   ├── metrics
│   ├── nodeselector
│   ├── openshift-scc
│   ├── workload-identity-logger
│   └── workload-identity-metrics
├── apigee-telemetry.yaml
└── kustomization.yaml

Ecco come probabilmente apparirebbero i file telemetry/kustomization.yaml per impostazione predefinita:

resources:
- apigee-telemetry.yaml

components:
- ./components/metrics
# - ./components/workload-identity-metrics
# - ./components/logger
# - ./components/workload-identity-logger
# - ./components/http-proxy
# - ./components/nodeselector/
# - ./components/imagepullsecret
# - ./components/openshift-scc

Possiamo vedere che ./components/logger è stato commentato, il che significa semplicemente che non abbiamo attivato uGoogle Clod logger per impostazione predefinita. Per attivarlo, puoi semplicemente rimuovere il commento dalla riga come segue:

components:

- ./components/logger

Analogamente, per disabilitare le metriche, è possibile commentare la riga ./components/metrics:

...
components:
...
# - ./components/metrics
…

Le sezioni seguenti illustreranno tutti questi vari componenti, quando possono essere utilizzati e come possono essere configurati.

OpenShift

Per gli utenti che desiderano installare Apigee Hybrid in un cluster OpenShift, potrebbe essere necessario abilitare alcuni componenti/risorse prima di eseguire l'installazione. (Questo passaggio è necessario se non si utilizza lo script per eseguire l'installazione). I file che devono essere modificati sono:

• overlays/initialization/openshift/kustomization.yaml . Nella sezione resources:, rimuovere il commento:

  # - ../../../bases/initialization/openshift/
  

• overlays/instances/{INSTANCE_NAME}/datastore/kustomization.yaml Rimuovi il commento:

  # - ./components/openshift-scc
  

  e rimuovere il commento dal campo "components:" se è ancora commentato.

• overlays/instances/{INSTANCE_NAME}/telemetry/kustomization.yaml Rimuovi il commento:

  # - ./components/openshift-scc
  

  e rimuovere il commento dal campo "components:" se è ancora commentato.

A questo punto è possibile procedere con la fase di installazione.

imagepullsecret

Questo componente può essere abilitato quando si hanno immagini memorizzate nel proprio repository privato. Per scaricare immagini da un repository privato, è possibile creare un secret di Kubernetes contenente i propri dati di autenticazione e quindi farvi riferimento al suo interno. Vedere Configurazione di imagePullSecrets (facoltativo) per le istruzioni. Consultare Scaricare un'immagine da un registro privato | Kubernetes nella documentazione di Kubernetes per ulteriori informazioni.

Disponibile in:

• overlays/controllers/apigee-controller
• overlays/controllers/istiod
• overlays/instances/{INSTANCE_NAME}/datastore
• overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
• overlays/instances/{INSTANCE_NAME}/organization
• overlays/instances/{INSTANCE_NAME}/redis
• overlays/instances/{INSTANCE_NAME}/telemetry

Abilitazione:

Rimuovere il commento dalla riga "./components/imagepullsecret/" nei rispettivi file kustomization.yaml ove necessario.

Modifiche da apportare:

• components/imagepullsecret/patch.yaml
  • OBBLIGATORIO Aggiungi i nomi segreti pertinenti all'elenco in spec.template.spec.imagePullSecrets

Utilizzo:

1. Se non hai ancora installato Apigee Hybrid, puoi continuare con i passaggi di installazione e queste modifiche verranno applicate automaticamente.

2. Se hai già installato Apigee Hybrid, dovrai applicare queste nuove modifiche utilizzando:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

nodeselector

Questo componente consente di pianificare i pod per una risorsa Apigee su nodi specifici. Consulta Assegnazione dei Pod ai Nodi | Kubernetes per ulteriori informazioni.

Disponibile in:

• overlays/controllers/apigee-controller
• overlays/controllers/istiod
• overlays/instances/{INSTANCE_NAME}/datastore
• overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
• overlays/instances/{INSTANCE_NAME}/organization
• overlays/instances/{INSTANCE_NAME}/redis
• overlays/instances/{INSTANCE_NAME}/telemetry

Abilitazione:

Rimuovere il commento dalla riga "./components/nodeselector" nei rispettivi file kustomization.yaml ove necessario.

Modifiche da apportare:

• components/nodeselector/patch.yaml
  • FACOLTATIVO Modifica il valore dell'etichetta del selettore del nodo da apigee-runtime o apigee-data a quello desiderato.

Utilizzo:

1. Se non hai ancora installato Apigee Hybrid, puoi continuare con i passaggi di installazione e queste modifiche verranno applicate automaticamente.

2. Se hai già installato Apigee Hybrid, dovrai applicare queste nuove modifiche utilizzando:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

identità del carico di lavoro

Nell'ecosistema Apigee Hybrid, diversi container richiedono autorizzazioni per effettuare determinate chiamate API al piano di controllo / gestione di Apigee. L'identità del carico di lavoro consiste nel concedere ai pod (e ai container al loro interno) queste autorizzazioni. Risorse utili per approfondire l'argomento includono: - Introduzione a Workload Identity: una migliore autenticazione per le applicazioni GKE | Blog di Google Cloud - Utilizzare Workload Identity | Documentazione di Kubernetes Engine | Google Cloud

Disponibile in:

• overlays/instances/{INSTANCE_NAME}/datastore
• overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
• overlays/instances/{INSTANCE_NAME}/organization
• overlays/instances/{INSTANCE_NAME}/redis
• overlays/instances/{INSTANCE_NAME}/telemetry

Prerequisito:

Prima di poter utilizzare Workload Identity, devi concedere le autorizzazioni pertinenti all'interno del tuo progetto Google Cloud utilizzando:

    gcloud iam service-accounts add-iam-policy-binding \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:${ORG_NAME}.svc.id.goog[${APIGEE_NAMESPACE}/${KSA_NAME}]" \
        ${GSA_NAME}@${ORG_NAME}.iam.gserviceaccount.com

dove: - ${ORG_NAME} - Il nome della tua organizzazione Apigee. - ${APIGEE_NAMESPACE} - Lo spazio dei nomi Kubernetes in cui sono stati installati i componenti Apigee. Questo sarebbe di solito apigee a meno che non venga modificato esplicitamente dall'utente durante l'installazione - ${KSA_NAME} - Il nome dello spazio dei nomi di Kubernetes. Dovrai eseguire questo comando per ogni account di servizio Kubernetes menzionato in Account di servizio Kubernetes - ${GSA_NAME} - Il nome dell'account di servizio Google Cloud. Se non hai apportato alcuna modifica durante l'installazione, questo avrà il valore apigee-all-sa. Se si configurano più account di servizio Google Cloud per singoli componenti, è necessario associare il KSA_NAME al GSA_NAME corrispondente. È possibile confrontare le tabelle in Account di servizio Google Cloud con Account di servizio Kubernetes per trovare gli equivalenti.

Abilitazione:

Rimuovere il commento dalla riga ./components/workload-identity nei rispettivi file kustomization.yaml, se necessario. Si noti che all'interno della telemetria, disponiamo di componenti aggiuntivi separati per l'identità del carico di lavoro per i componenti metrics e logger che possono essere abilitati individualmente.

Utilizzo:

1. Se non hai ancora installato l'ibrido, puoi semplicemente attivare workload-identity come indicato nella sezione precedente e continuare con l'installazione, che utilizzerà automaticamente workload-identity.

2. Se hai già installato Apigee Hybrid, dovrai applicare queste nuove modifiche utilizzando:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

http-proxy

Puoi configurare un server proxy in ciascuno dei seguenti componenti in modo che il traffico per quel componente passi attraverso il proxy HTTP configurato per quel componente. Puoi configurare il proxy per ogni componente Apigee singolarmente.

Disponibile in:

• overlays/instances/{INSTANCE_NAME}/datastore
• overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
• overlays/instances/{INSTANCE_NAME}/organization
• overlays/instances/{INSTANCE_NAME}/telemetry

Abilitazione:

Rimuovere il commento dalla riga "./components/http-proxy/" nei rispettivi file kustomization.yaml ove necessario.

Modifiche da apportare:

• components/http-proxy/patch.yaml I seguenti parametri possono essere configurati sotto spec.httpForwardProxy
  • scheme: NECESSARIO Uno deiHTTP OHTTPS
  • host: OBBLIGATORIO L'indirizzo host del tuo proxy
  • port: OBBLIGATORIO Il numero di porta
  • username: FACOLTATIVO Il nome utente associato al tuo proxy
  • password: FACOLTATIVO La password per accedere al proxy

Utilizzo:

1. Se non hai ancora installato Apigee Hybrid, puoi continuare con i passaggi di installazione e queste modifiche verranno applicate automaticamente.

2. Se hai già installato Apigee Hybrid, dovrai applicare queste nuove modifiche utilizzando:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

logger e metriche

È possibile abilitare o disabilitare singolarmente il logger o le metriche all'interno di overlay/instances/{INSTANCE_NAME}/telemetry. Per impostazione predefinita, il logger è disabilitato e le metriche sono abilitate. Per abilitarli o disabilitarli è sufficiente decommentare o commentare le relative righe nel file telemetry/kustomization.yaml.

gcs-backup e gcs-restore

Questo componente Kustomize può essere utilizzato per eseguire il backup e il ripristino del database Cassandra su Google Cloud Storage.

Disponibile in:

• overlays/instances/{INSTANCE_NAME}/datastore

Prerequisito:

1. Scarica le chiavi degli account di servizio di Google Cloud per un account che ha il ruolo di amministratore degli oggetti di archiviazione.

   • Se hai utilizzato lo script per eseguire l'installazione e non hai utilizzato le identità di carico di lavoro, puoi riutilizzare le chiavi scaricate disponibili nella cartella service-accounts creata dallo script.

   • Puoi anche utilizzare lo script create-service-account.sh per creare un nuovo account di servizio e scaricarne le chiavi:

     ./tools/create-service-accounts=.sh --env prod --profile apigee‑cassandra
     

2. Una volta scaricate le chiavi, è necessario creare un secret di Kubernetes con il nome apigee-cassandra-backup-and-restore-gcp-sa-key, operazione che può essere eseguita utilizzando il comando:

   kubectl create secret generic "apigee-cassandra-backup-and-restore-gcp-sa-key" \
             --from-file="dbbackup_key.json=${PATH_TO_SA_KEY}" \
             -n "${APIGEE_NAMESPACE}"
   

   Dove:

   • ${PATH_TO_SA_KEY} - Percorso del file contenente le chiavi dell'account di servizio.
   • ${APIGEE_NAMESPACE} - Lo spazio dei nomi Kubernetes in cui sono stati installati i componenti di Apigee. In genere è apigee, a meno che non sia stato modificato esplicitamente durante l'installazione

In alternativa, è possibile utilizzare il file modello templates/secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml per creare questo segreto.

Abilitazione:

• Se si desidera abilitare il backup, rimuovere il commento dalla riga "./components/gcs-backup" nel file kustomization.yaml del datastore.
• Se si desidera ripristinare un backup, decommentare la riga "./components/gcs-restore" nel file kustomization.yaml del datastore.

Modifiche solo per il backup

• components/gcs-backup/apigee-datastore-patch.yaml
  • OBBLIGATORIO Modifica il valore della variabile di ambiente DATABASE_STORAGE_BUCKET, che avrà il formato gs://BUCKET_NAME e punterà al bucket Google Cloud Storage in cui devono essere eseguiti i backup dei dati. La descrizione corrisponde a dbStorageBucket descritto qui.
• components/gcs-backup/cron-patch.yaml
  • OBBLIGATORIO Modificare spec.schedule per specificare la frequenza del backup. Il campo accetta il formato standard di pianificazione Crontab. La descrizione corrisponde al programma descritto qui.
  • OBBLIGATORIO Modifica il valore della variabile di ambiente DATABASE_STORAGE_BUCKET che avrà il formato gs://NOME_BUCKET e punterà al bucket di Google Cloud Storage in cui è necessario eseguire il backup dei dati. La descrizione corrisponde a dbStorageBucket descritto qui.
  • FACOLTATIVO Modifica il valore di HTTP_PROXY_URL in modo che punti a qualsiasi proxy configurato. Il formato potrebbe essere il seguente:
    • http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
    • https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
    • http://${HOST_IP_ADDRESS}:${HOST_PORT}
    • http://${HOST_IP_ADDRESS>:${HOST_PORT}

Esecuzione del backup

È possibile eseguire il backup con il seguente comando:

kubectl apply -k overlays/instances/{INSTANCE_NAME}

Per applicare le modifiche e abilitare il backup:

Modifiche solo per il ripristino

• components/gcs-restore/apigee-datastore-patch.yaml
  • OBBLIGATORIO Modificare il valore della variabile di ambiente DATABASE_STORAGE_BUCKET, che avrà il formato gs://NOME_BUCKET e punterà al bucket di Google Cloud Storage in cui è necessario eseguire il backup dei dati. La descrizione corrisponde a dbStorageBucket descritto qui.
• components/gcs-restore/job-patch.yaml
  • OBBLIGATORIO Modificare il valore della variabile di ambiente DATABASE_STORAGE_BUCKET, che avrà il formato gs://NOME_BUCKET e punterà al bucket di Google Cloud Storage in cui è necessario eseguire il backup dei dati.
  • OBBLIGATORIO Modificare il valore della variabile di ambiente BACKUP_SNAPSHOT_TIMESTAMP. La descrizione corrisponde a restore:snapshotTimestamp descritto qui.
  • FACOLTATIVO Modifica il valore di HTTP_PROXY_URL in modo che punti a qualsiasi proxy configurato. Il formato potrebbe essere il seguente:
    • http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
    • https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
    • http://${HOST_IP_ADDRESS}:${HOST_PORT}
    • http://${HOST_IP_ADDRESS}:${HOST_PORT}

Esecuzione del ripristino:

Per informazioni di base sul ripristino dei backup, vedere Ripristino dei backup | Apigee X | Google Cloud

1. Crea un nuovo cluster Kubernetes con un nuovo namespace in cui ripristinare la distribuzione runtime ibrida. Non è possibile utilizzare lo stesso cluster e lo stesso namespace utilizzati per l'installazione ibrida originale.

2. Installa Hybrid nel nuovo cluster con le impostazioni configurate sopra, oltre a qualsiasi altra impostazione tu desideri:

   • È possibile utilizzare l'installazione di base e l'installazione ibrida nel nuovo namespace:

   ./tools/apigee-hybrid-setup.sh \
   --cluster-name $CLUSTER_NAME \
   --cluster-region $CLUSTER_LOCATION \
   --namespace ${NEW_APIGEE_NAMESPACE}
   

   • In alternativa, segui la procedura di installazione personalizzata di Apigee Hybrid per configurare gli elementi in base alle tue preferenze.

3. Una volta completato il ripristino, tutte le risorse presenti nel vecchio namespace potranno essere eliminate e trasferite al nuovo namespace.

Per ulteriori informazioni, vedere Ripristino dei backup.

non-gcs-backup e non-gcs-restore

Questo componente Kustomize può essere utilizzato per eseguire il backup e il ripristino del database Cassandra su Google Cloud Storage.

Disponibile in:

• overlays/instances/{INSTANCE_NAME}/datastore

Prerequisito:

1. È possibile utilizzare i passaggi già presenti nella documentazione per Configurare il server e SSH.

2. Dai passaggi precedenti, dovrai utilizzare la chiave privata SSH disponibile nel file "ssh_key" generato seguendo i passaggi precedenti. Verrà quindi creato un secret Kubernetes denominato apigee-cassandra-backup-and-restore-gcp-sa-key che contiene questa chiave privata SSH.

   ---

   Nota: Assicurati che il file della chiave privata SSH abbia una nuova riga alla fine.

   ---

   Il secret di Kubernetes può essere creato utilizzando il seguente comando:

   kubectl create secret generic "apigee-cassandra-backup-and-restore-key-file" \
           --from-file="key=${PATH_TO_SSH_PRIVATE_KEY}" \
           -n "${APIGEE_NAMESPACE}"
   

   Dove:

   • ${PATH_TO_SSH_PRIVATE_KEY} - Percorso del file contenente la chiave privata SSH
   • ${APIGEE_NAMESPACE} - Lo spazio dei nomi Kubernetes in cui sono stati installati i componenti di Apigee. Di solito si tratta di Apigee, a meno che non venga esplicitamente modificato durante l'installazione.

   In alternativa, puoi utilizzare il file modello templates/secret-apigee-cassandra-backup-and-restore-key-file.yaml per creare questo secret.

Attivazione in corso:

• Se si desidera abilitare il backup, rimuovere il commento dalla riga "./components/non-gcs-backup" nel file kustomization.yaml del datastore.
• Se si desidera ripristinare un backup, decommentare la riga "./components/non-gcs-restore" nel file kustomization.yaml del datastore.

Modifiche solo per il backup

• components/non-gcs-backup/apigee-datastore-patch.yaml
  • OBBLIGATORIO Modificare il valore di BACKUP_SERVER_IP. La descrizione corrisponde a BACKUP_SERVER_IP descritto qui.
  • OBBLIGATORIO Modificare il valore di BACKUP_STORAGE_DIR. La descrizione corrisponde a BACKUP_STORAGE_DIR descritta qui.
• components/non-gcs-backup/cron-patch.yaml
  • OBBLIGATORIO Modifica spec.schedule per specificare la frequenza del backup. Il campo accetta il formato standard di pianificazione Crontab. La descrizione corrisponde alla programmazione descritta qui.
  • OBBLIGATORIO Modificare il valore di BACKUP_SERVER_IP. La descrizione corrisponde a BACKUP_SERVER_IP descritto qui.
  • OBBLIGATORIO Modificare il valore di BACKUP_STORAGE_DIR. La descrizione corrisponde a BACKUP_STORAGE_DIR descritta qui.
  • (FACOLTATIVO) Modifica il valore di HTTP_PROXY_URL in modo che punti a qualsiasi proxy configurato. Il formato potrebbe essere il seguente:
    • http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
    • https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
    • http://${HOST_IP_ADDRESS}:${HOST_PORT}
    • http://${HOST_IP_ADDRESS}:${HOST_PORT}

Esecuzione del backup

È possibile eseguire il backup con il seguente comando:

kubectl apply -k overlays/instances/{INSTANCE_NAME}

Per applicare le modifiche e abilitare il backup:

Modifiche solo per il backup

• components/non-gcs-restore/apigee-datastore-patch.yaml
  • OBBLIGATORIO Modifica il valore di BACKUP_SERVER_IP. La descrizione corrisponde a BACKUP_SERVER_IP descritta qui.
  • OBBLIGATORIO Modificare il valore di BACKUP_STORAGE_DIR. La descrizione corrisponde a BACKUP_STORAGE_DIR descritto qui.
• components/non-gcs-restore/job-patch.yaml
  • OBBLIGATORIO Modifica il valore della variabile di ambiente BACKUP_SNAPSHOT_TIMESTAMP. La descrizione corrisponde a restore:snapshotTimestamp descritta qui.
  • OBBLIGATORIO Modifica il valore di BACKUP_SERVER_IP. La descrizione corrisponde a BACKUP_SERVER_IP descritto qui.
  • OBBLIGATORIO Modifica il valore di BACKUP_STORAGE_DIR. La descrizione corrisponde a BACKUP_STORAGE_DIR descritta qui.
  • FACOLTATIVO Modifica il valore di HTTP_PROXY_URL in modo che punti a qualsiasi proxy configurato. Il formato potrebbe essere il seguente:
    • http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
    • https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
    • http://${HOST_IP_ADDRESS}:${HOST_PORT}
    • http://${HOST_IP_ADDRESS}:${HOST_PORT}

Esecuzione del ripristino:

Per una panoramica sul ripristino dei backup, vedere Panoramica sul ripristino di Cassandra.

1. Crea un nuovo cluster Kubernetes con un nuovo namespace in cui ripristinare la distribuzione runtime ibrida. Non è possibile utilizzare lo stesso cluster e lo stesso namespace utilizzati per l'installazione ibrida originale.

2. Installa Hybrid nel nuovo cluster con le impostazioni configurate sopra, oltre a qualsiasi altra impostazione che desideri: Puoi utilizzare l'installazione di base e installare Hybrid nel nuovo spazio dei nomi:

   ./tools/apigee-hybrid-setup.sh \
     --cluster-name $CLUSTER_NAME \
     --cluster-region $CLUSTER_LOCATION \
     --namespace ${NEW_APIGEE_NAMESPACE}
   

   In alternativa, segui la procedura di installazione personalizzata di Apigee Hybrid per configurare gli elementi in base alle tue preferenze.

3. Una volta completato il ripristino, tutte le risorse presenti nel vecchio namespace potranno essere eliminate e trasferite al nuovo namespace.

   Per ulteriori informazioni, vedere Pianificazione dei backup su un server remoto.

http-client

Per istruzioni, vedi Attivare i client HTTP | Apigee.

Disponibile in:

• overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}

Abilitazione:

Rimuovere il commento dalla riga "./components/http-client" nel rispettivo file route-config/${ENV_GROUP}/kustomization.yaml

Modifiche da apportare:

• Non sono necessarie modifiche obbligatorie.

Utilizzo:

1. Se non hai ancora installato Apigee Hybrid, puoi continuare con i passaggi di installazione e queste modifiche verranno applicate automaticamente.

2. Se hai già installato Apigee Hybrid, dovrai applicare queste nuove modifiche utilizzando:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

non-client sni

Equivalente del già esistente Come configurare un client non SNI | Apigee.

Disponibile in:

• overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}

Abilitazione:

Rimuovi il commento dalla riga "./components/non-sni-client" nel file route-config/${ENV_GROUP}/kustomization.yaml corrispondente

Modifiche da apportare:

• components/non-sni-client/apigee-route.yaml
  • NECESSARIO credentialName corrispondenze della descrizionecredential_name descritto qui.

Utilizzo:

1. Se non hai ancora installato Apigee Hybrid, puoi continuare con i passaggi di installazione e queste modifiche verranno applicate automaticamente.

2. Se hai già installato Apigee Hybrid, dovrai applicare queste nuove modifiche utilizzando:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

http-and-non-sni-client

Per le istruzioni, vedere Abilita il supporto per client non SNI e HTTP | Apigee.

Abilitazione:

Rimuovi il commento dalla riga "./components/http-and-non-sni-client" nel file route-config/${ENV_GROUP}/kustomization.yaml corrispondente

Modifiche da apportare:

• components/http-and-non-sni-client/apigee-route.yaml
  • NECESSARIO credentialName corrispondenze della descrizionecredential_name descritto qui.

Utilizzo:

1. Se non hai ancora installato Apigee Hybrid, puoi continuare con i passaggi di installazione e queste modifiche verranno applicate automaticamente.

2. Se hai già installato Apigee Hybrid, dovrai applicare queste nuove modifiche utilizzando:

   kubectl apply -k overlays/instances/{INSTANCE_NAME}
   

più regioni

Questo componente può essere utilizzato durante la configurazione di un deployment Cassandra multiregionale. Per maggiori informazioni, consulta Deployment in più regioni su GKE e GKE On-Prem.

Attivazione in corso:

Rimuovi il commento dalla riga "./components/multi-region" nel file datastore/kustomization.yaml

Modifiche da apportare:

• components/multi-region/cassandra-data-replication.yaml

  • OBBLIGATORIO source.region Il nome del data center Cassandra di origine che verrà utilizzato per replicare i dati. Può essere identificato utilizzando il seguente comando nel cluster sorgente:

  kubectl get apigeedatastore -n ${APIGEE_NAMESPACE} -o=jsonpath='{.items[*].spec.components.cassandra.properties.datacenter}'
  

• componenti/multi-regione/patch.yaml

  • OBBLIGATORIO spec.components.properties.multiRegionSeedHost L'IP pod di uno qualsiasi dei pod Cassandra di origine. Possiamo utilizzare:

  kubectl get pods -n ${APIGEE_NAMESPACE} -o wide
  

  • Per elencare tutti i pod e ottenere l'indirizzo IP di ciascun pod Cassandra, utilizzare il seguente comando:

  kubectl get pods -o wide -n apigee
  

  L'output dovrebbe essere simile al seguente:

  NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
  apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
  apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
  apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch
  

Per maggiori informazioni, consulta Prerequisiti per GKE in "Deployment in più regioni su GKE, GKE On-Prem e AKS":

Utilizzo:

L'utilizzo di questo componente ha senso soprattutto quando configuri Apigee Hybrid in un nuovo cluster e hai già un'altra configurazione funzionante di Apigee Hybrid.

1. Sia il cluster nuovo che quello esistente devono utilizzare gli stessi certificati TLS per garantire una comunicazione corretta tra i pod di Cassandra. Quindi dovremo copiare il segreto apigee-root-certificate dal cluster esistente e utilizzarlo anche in quello nuovo:

2. Esegui:

   kubectl config get-contexts
   

   • Per ottenere un elenco di tutti i contesti Kubernetes, esegui

   kubectl config use-context SOURCE_CLUSTER_CONTEXT
   

   dove SOURCE_CLUSTER_CONTEXT è il nome del contesto del cluster Kubernetes di origine.

3. Memorizza il secret del certificato radice in un file:

   kubectl get secret/apigee-root-certificate -n cert-manager -o yaml > apigee-root-certificate.yaml
   

4. Passa al nuovo cluster in cui stai installando Apigee Hybrid.

   kubectl config use-context ${NEW_CLUSTER_CONTEXT}
   

5. Crea il secret principale nel nuovo cluster:

   kubectl -n cert-manager apply -f apigee-root-certificate.yaml
   

6. Disabilita la creazione di un nuovo certificato radice. Questo garantirà che non creeremo un nuovo apigee-root-certificate e finiremo per sovrascrivere quello che abbiamo creato nel passaggio precedente.

7. Rimuovi il commento dalle seguenti righe nel file overlays/initialization/certificates/kustomization.yaml:

   # components:
   # - ./components/disable-apigee-root-certificate-generation
   

8. Continua con il resto dell'installazione di Apigee Hybrid utilizzando l'installazione di base di Apigee Hybrid o l'installazione personalizzata di Apigee Hybrid. Ad esempio, seguendo l'installazione Basic Apigee Hybrid, è possibile eseguire:

   ./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION
   

9. Verifica lo stato della ricompilazione utilizzando il seguente comando.

   ---

   Nota: l'operazione di ricompilazione può richiedere diverse ore, a seconda delle dimensioni dei dati.

   ---

   kubectl -n ${APIGEE_NAMESPACE} get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
   

10. Verifica i processi di ricompilazione dai log. Inoltre, verifica la dimensione dei dati utilizzando il comando nodetool status:

    kubectl logs apigee-cassandra-default-0 -f -n ${APIGEE_NAMESPACE}
    kubectl exec apigee-cassandra-default-0 -n ${APIGEE_NAMESPACE}  -- nodetool -u ${JMX_USER} -pw ${JMX_PASSWORD} status
    

11. Verifica lo stato della ricompilazione utilizzando il seguente comando.

    ---

    Nota: L'operazione di ricostruzione può richiedere fino a diverse ore a seconda delle dimensioni dei dati.

    ---

    kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
    

    I risultati dovrebbero essere simili a questi:

    {
    "rebuildDetails": {
    "apigee-cassandra-default-0": {
      "state": "complete",
      "updated": 1623105760
    },
    "apigee-cassandra-default-1": {
      "state": "complete",
      "updated": 1623105765
    },
    "apigee-cassandra-default-2": {
      "state": "complete",
      "updated": 1623105770
    }
    },
    "state": "complete",
    "updated": 1623105770
    }
    

    Vedi anche: Implementazione multiregionale.

12. Rimozione delle seguenti righe da components/multi-region/patch.yaml:

      properties:
        multiRegionSeedHost: {IP_ADDRESS} # To be modified. REQUIRED
    

13. Applica le modifiche:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}
    

Concetti

Centro immagini

Le immagini dei container Docker sono generalmente specificate nel formato:

${REGISTRY_HOST_PATH}/${IMAGE_NAME}:${IMAGE_TAG}

oppure quelli che utilizzano un digest hanno questo aspetto:

${REGISTRY_HOST_PATH}/${IMAGE_NAME}@${DIGEST}

Apigee utilizza il concetto di "Image Hub", che nei formati sopra indicati si riferisce a ${REGISTRY_HOST_PATH}. Il valore predefinito di Image Hub è gcr.io/apigee-release/hybrid/.

(Le immagini che utilizzano DIGEST dovranno essere impostate singolarmente in ogni sottocomponente)

Apigee costruisce il percorso finale dell'immagine combinando i seguenti valori:

• "Image Hub", che può essere sostituito in apigee-hybrid-config.yaml (consulta la sezione Utilizzo di immagini Docker da repository privati per i passaggi dettagliati su come sostituire Image Hub).
• Il valore di IMAGE_TAG si ottiene dal campo version, presente all'interno del file yaml per ciascuno dei singoli componenti (ad esempio, apigee-organization.yaml). Apigee tagga le immagini con la versione di Apigee Hybrid, il che significa che IMAGE_TAG è 1.8 per Apigee Hybrid versione 1.8
• IMAGE_NAME viene determinato implicitamente dal nome del contenitore in cui verrà utilizzata l'immagine. Ad esempio, per ilapigee-runtime contenitore, ilIMAGE_NAME sarà apigee-runtime.

Pertanto, un esempio completo di percorso immagine sarebbe gcr.io/apigee-release/hybrid/apigee-runtime:1.8.0

In questo modo, viene costruito il percorso finale dell'immagine, che verrà poi utilizzato all'interno di ciascun contenitore nei rispettivi pod.

Account di servizio Google Cloud

Gli account di servizio di Google Cloud sono account utilizzati dalle applicazioni per effettuare chiamate autorizzate alle API di Google. È possibile scaricare le chiavi dell'account di servizio Google Cloud, che possono poi essere utilizzate per l'autenticazione. Apigee richiede all'utente di fornire le chiavi dell'account di servizio creando dei segreti. Di seguito sono riportati i nomi dei componenti e il nome predefinito del segreto in cui vengono cercate le chiavi dell'account di servizio:

Componente	Sottocomponente	Nome segreto predefinito di Kubernetes contenente la chiave dell'account di servizio
organizzazione
	connectAgent	apigee-connect-agent-gcp-sa-key-${ORG_NAME}
	osservatore	apigee-watcher-gcp-sa-key-${ORG_NAME}
	mart	apigee-mart-gcp-sa-key-${ORG_NAME}
	udca	apigee-udca-gcp-sa-key-${ORG_NAME}
	ingressGateways	N/D
ambiente
	runtime	apigee-runtime-gcp-sa-key-${ORG_NAME}-${ENV_NAME}
	udca	apigee-udca-gcp-sa-key-${ORG_NAME}-${ENV_NAME}
	sincronizzatore	apigee-synchronizer-gcp-sa-key-${ORG_NAME}-${ENV_NAME}
telemetria
	metriche	apigee-metrics-gcp-sa-key
	containerLogs	apigee-logger-gcp-sa-key

Service account Kubernetes

Gli account di servizio Kubernetes forniscono identità ai pod nel cluster. Per impostazione predefinita, il controller Apigee li crea automaticamente. Tuttavia, se vuoi ignorare la creazione (ad esempio, quando utilizzi le identità dei workload), puoi farlo specificando il campo podServiceAccountName nei vari sottocomponenti.

Elenco dei componenti e dei rispettivi sottocomponenti in cui è possibile specificare l'account di servizio Kubernetes, insieme al nome predefinito dell'account di servizio Kubernetes quando si abilita la patch di identità del carico di lavoro.

Componente	Sottocomponente	Nome predefinito (disponibile quando è stata abilitata la patch di identità del carico di lavoro)
organizzazione
	connectAgent	apigee-connect-agent-svc-account-${ORG_NAME}
	osservatore	apigee-watcher-svc-account-${ORG_NAME}
	mart	apigee-mart-svc-account-${ORG_NAME}
	udca	apigee-udca-svc-account-${ORG_NAME}
ambiente
	sincronizzatore	apigee-synchronizer-svc-account-${ORG_NAME}-${ENV_NAME}
	udca	apigee-udca-svc-account-${ORG_NAME}-${ENV_NAME}
	runtime	apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME}
datastore
	cassandra	apigee-datastore-svc-account
telemetria
	metricsApp	apigee-metricsApp-svc-account
	metricsProxy	apigee-metricsProxy-svc-account
	metricsAdapter	apigee-metricsAdapter-svc-account
	containerLogs	apigee-container-logs-svc-account

Identità di workload

Le workload identity consentono ai pod (che utilizzano i service account Kubernetes) in esecuzione in GKE di eseguire l'autenticazione direttamente con le API Google Cloud senza richiedere le chiavi del account di servizio Google Cloud.

Aggiunta di un nuovo ambiente

.
├── ...
├── instances/instance1/components
│   ├── ...
│   ├── environments
│   │   ├── dev
│   │   │   └── apigee-environment.yaml
│   │   │   └── secrets.yaml
│   │   └── new-env-name (new)
│   │       └── apigee-environment.yaml (new)
│   │       └── secrets.yaml (new)
└── ...

Aggiungere un nuovo ambiente è semplicissimo:

1. Creazione di una nuova cartella all'interno della directory environments (o comunque sia strutturata la tua cartella).
2. Copia il file apigee-environment.yaml da qualsiasi ambiente esistente nella nuova cartella.
3. Se desideri creare un nuovo account di servizio e chiavi di crittografia per il nuovo ambiente, copia i file secrets.yaml nella nuova cartella e rinomina i segreti in modo appropriato per distinguerli dagli altri ambienti esistenti (in genere, questo si fa aggiungendo il nome dell'ambiente come suffisso).
4. Apportare le modifiche appropriate a apigee-environment.yaml, come:
   • Modificare il nome dell'ambiente
   • Se si intende creare nuovi account di servizio e chiavi di crittografia, è necessario che vengano correttamente referenziati nel file YAML.
5. Applicazione degli yamls:

kubectl apply -f components/environments/new-env-name/secrets.yaml
kubectl apply -f components/environments/new-env-name/apigee-environment.yaml

Utilizzo dell'eliminazione forzata in Apigee Datastore

Se l'eliminazione del datastore non procede per qualsiasi motivo, ora è possibile forzare l'eliminazione del datastore Apigee utilizzando i seguenti comandi, indipendentemente dallo stato attuale del cluster.

---

Nota: L'utilizzo della cancellazione forzata eliminerà anche i PVC. Quindi, se l'attuale implementazione di Apigee Hybrid è dovuta a un singolo motivo, esegui un backup prima di procedere.

---

---

Nota: L'utilizzo dell'eliminazione forzata in cluster multi-regione richiede una pulizia manuale nelle altre regioni al termine dell'eliminazione del datastore, al fine di mantenere Cassandra in uno stato integro. Consulta la guida alla risoluzione dei problemi per le istruzioni su come eseguire la pulizia manuale.

---

1. Eliminareapigeeds nelapigee spazio dei nomi:

   Kubectl delete -n apigee apigeeds default
   

   Se questa fase si blocca, è possibile uscirne utilizzando CTRL + C.

2. Modifica un nuovo apigeeds:

   Kubectl edit -n apigee apigeeds default
   

3. Aggiungere/aggiornare il campo forceDelete nelle specifiche del datastore Apigee

   spec:
   forceDelete: true
   

4. Salva il file ed esci.

Ora attendi che il datastore venga eliminato. L'eliminazione di tutte le risorse Cassandra può richiedere alcuni minuti.

Comprendere la sceneggiatura

apigee-hybrid-setup.sh Lo script esegue alcune convalide di base e aiuta ad automatizzare i passaggi che altrimenti dovresti eseguire se desideri una personalizzazione più dettagliata, come documentato in Installazione ibrida personalizzata di Apigee. Anche con un'installazione personalizzata, è comunque possibile utilizzare parzialmente lo script per agevolare determinate attività.

È possibile eseguire ./tools/apigee-hybrid-setup.sh --help per visualizzare un elenco dei flag supportati e ottenere ulteriore assistenza con lo script. Al momento sono supportati i seguenti flag:

• --namespacePer impostazione predefinita, lo script installa tutti i componenti nelapigee spazio dei nomi. È possibile modificare questo comportamento specificando il nome dello spazio dei nomi tramite questo flag.
• --org Utilizzato per fornire il nome dell'organizzazione Apigee. Se non specificato, viene utilizzato per impostazione predefinita il progetto Google Cloud attualmente selezionato in gcloud
• --envgroup Utilizzato per specificare il nome del gruppo di ambienti all'interno dell'organizzazione. Se non specificato, si tenta di interrogare le API del piano di controllo per determinare il nome del gruppo di ambienti. Se vengono rilevati più gruppi di ambienti, viene restituito un errore e lo script termina.
• --env Utilizzato per fornire il nome dell'ambiente all'interno della tua organizzazione. Se non specificato, si tenta di interrogare le API del piano di controllo per determinare il nome dell'ambiente. Se vengono rilevati più ambienti o se l'ambiente non fa parte del gruppo di ambienti, viene restituito un errore e lo script termina.
• --cluster-name Il nome del cluster Kubernetes.
• --cluster-region La regione in cui si trova il cluster Kubernetes
• --gcp-project-id L'ID progetto Google Cloud in cui esiste il cluster Kubernetes
• --ingress-domain Specifica il nome host/nome di dominio che verrà utilizzato per generare i certificati TLS autofirmati per istio ingress-gateway. Se non ne viene specificato alcuno, si tenta di determinarne il valore interrogando le API del piano di controllo per ottenerlo dal gruppo ambientale. Se si verificano problemi nella determinazione del gruppo di variabili d'ambiente o se sono configurati più nomi host per tale gruppo, viene restituito un errore e lo script termina.
• --generate-internal-tls-certs Questo genererà un secret di Kubernetes denominato apigee-ca che contiene una coppia di certificati e chiavi generata da noi.
• --create-ingress-tls-certsQuesto genererà un segreto chiamato{ORG_NAME}-{ENV_GROUP_NAME} (derivato dal nome dell'organizzazione e del gruppo d'ambiente) all'interno dello spazio dei nomi istio-system che conterrà una coppia di certificati e chiavi che verrà utilizzata per la comunicazione TLS. Il nome di dominio utilizzato per generare questi certificati deriva dal valore presente nella configurazione di envgroup. In caso di conflitti (ad esempio, quando vengono rilevati più domini), verranno visualizzati i relativi messaggi di errore.
• --create-gcp-sa-and-secrets Crea un singolo account di servizio Google Cloud nel progetto Google Cloud, scarica le chiavi e quindi crea i segreti Kubernetes contenenti la chiave. I nomi dei segreti possono essere trovati negli account di servizio di Google Cloud.
• --fill-values Sostituisce i valori di org, env, envgroup e altri nomi ovunque siano richiesti nei vari file yaml.
• --apply-configuration Questo creerà gli emittenti di certificati, le definizioni di risorse personalizzate, i webhook, i ruoli e la risorsa controller. Le risorse verranno create nell'ordine corretto e il comando rimarrà bloccato finché non saranno tutte integre.
• -- rename-directories Rinominare l'ambiente e il gruppo di ambienti con i nomi corretti dell'ambiente e del gruppo di ambienti.
• --verbose Mostra l'output dettagliato per il debug.
• --help Visualizza le informazioni sull'utilizzo.
• --setup-all Questo eseguirà tutte le attività che possono essere svolte da questo script

Struttura delle cartelle di configurazione ibrida di Apigee

La cartella apigee-hybrid-setup ha la seguente struttura gerarchica predefinita:

.
├── bases
│   ├── controllers
│   │   ├── apigee-controller
│   │   │   ├── apigee-controller-deployment.yaml
│   │   │   └── kustomization.yaml
│   │   └── apigee-ingressgateway-manager
│   │       ├── apigee-ingressgateway-manager-deployment.yaml
│   │       └── kustomization.yaml
│   ├── datastore
│   │   └── backup-and-restore
│   │       ├── backup
│   │       │   ├── cronjob.yaml
│   │       │   └── kustomization.yaml
│   │       ├── common
│   │       │   ├── kustomization.yaml
│   │       │   ├── rbac.yaml
│   │       │   └── tls-certificate.yaml
│   │       └── restore
│   │           ├── job.yaml
│   │           └── kustomization.yaml
│   └── initialization
│       ├── certificates
│       │   ├── certificates-and-issuers.yaml
│       │   └── kustomization.yaml
│       ├── crds
│       │   ├── customresourcedefinition-apigeedatastores.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeedeployments.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeenvironments.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeredis.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeerouteconfigs.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeroutes.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeetelemetries.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-cassandradatareplications.apigee.cloud.google.com.yaml
│       │   └── kustomization.yaml
│       ├── openshift
│       │   ├── kustomization.yaml
│       │   └── scc.yaml
│       ├── rbac
│       │   ├── apigee-controller
│       │   │   ├── kustomization.yaml
│       │   │   └── rbac.yaml
│       │   └── apigee-embedded-ingress-controller
│       │       ├── cluster-role-bindings.yaml
│       │       ├── cluster-roles.yaml
│       │       ├── kustomization.yaml
│       │       └── service-account.yaml
│       └── webhooks
│           ├── kustomization.yaml
│           ├── mutatingwebhookconfiguration.yaml
│           └── validatingwebhookconfiguration.yaml
├── CONTRIBUTING.md
├── docs
│   └── api_references
│       ├── v1alpha1.md
│       └── v1alpha2.md
├── kokoro
│   ├── build.sh
│   ├── common.cfg
│   ├── continuous.cfg
│   ├── presubmit.cfg
│   └── release.cfg
├── LICENSE
├── overlays
│   ├── controllers
│   │   ├── apigee-controller
│   │   │   ├── apigee-hybrid-config.yaml
│   │   │   ├── components
│   │   │   │   ├── imagepullsecret
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   └── patch.yaml
│   │   │   │   └── nodeselector
│   │   │   │       ├── kustomization.yaml
│   │   │   │       └── patch.yaml
│   │   │   └── kustomization.yaml
│   │   ├── apigee-ingressgateway-manager
│   │   │   ├── apigee-ingressgateway-manager-deployment-patch.yaml
│   │   │   ├── apigee-istio-mesh-config.yaml
│   │   │   ├── components
│   │   │   │   ├── imagepullsecret
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   └── patch.yaml
│   │   │   │   └── nodeselector
│   │   │   │       ├── kustomization.yaml
│   │   │   │       └── patch.yaml
│   │   │   └── kustomization.yaml
│   │   └── kustomization.yaml
│   ├── initialization
│   │   ├── certificates
│   │   │   ├── apigee-ingressgateway-manager-certificate-patch.yaml
│   │   │   ├── apigee-serving-cert-patch.yaml
│   │   │   ├── components
│   │   │   │   └── disable-apigee-root-certificate-generation
│   │   │   │       └── kustomization.yaml
│   │   │   └── kustomization.yaml
│   │   ├── crds
│   │   │   └── kustomization.yaml
│   │   ├── ingress
│   │   │   ├── envoyfilter-1.11.yaml
│   │   │   └── kustomization.yaml
│   │   ├── namespace.yaml
│   │   ├── openshift
│   │   │   ├── kustomization.yaml
│   │   │   └── scc.yaml
│   │   ├── rbac
│   │   │   ├── apigee-controller
│   │   │   │   └── kustomization.yaml
│   │   │   ├── apigee-ingressgateway-manager
│   │   │   │   └── kustomization.yaml
│   │   │   └── kustomization.yaml
│   │   └── webhooks
│   │       ├── kustomization.yaml
│   │       ├── mutatingwebhookconfiguration.yaml
│   │       └── validatingwebhookconfiguration.yaml
│   └── instances
│       └── instance1
│           ├── datastore
│           │   ├── apigee-datastore.yaml
│           │   ├── components
│           │   │   ├── gcs-backup
│           │   │   │   ├── apigee-datastore-patch.yaml
│           │   │   │   ├── cron-patch.yaml
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── tls-certificate-patch.yaml
│           │   │   ├── gcs-restore
│           │   │   │   ├── apigee-datastore-patch.yaml
│           │   │   │   ├── job-patch.yaml
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── tls-certificate-patch.yaml
│           │   │   ├── http-proxy
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── imagepullsecret
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── multi-region
│           │   │   │   ├── cassandra-data-replication.yaml
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── nodeselector
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── non-gcs-backup
│           │   │   │   ├── apigee-datastore-patch.yaml
│           │   │   │   ├── cron-patch.yaml
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── tls-certificate-patch.yaml
│           │   │   ├── non-gcs-restore
│           │   │   │   ├── apigee-datastore-patch.yaml
│           │   │   │   ├── job-patch.yaml
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── tls-certificate-patch.yaml
│           │   │   ├── openshift-scc
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── scc.yaml
│           │   │   └── workload-identity
│           │   │       ├── kustomization.yaml
│           │   │       ├── patch.yaml
│           │   │       └── service-accounts.yaml
│           │   ├── kustomization.yaml
│           │   └── secrets.yaml
│           ├── environments
│           │   ├── kustomization.yaml
│           │   └── test
│           │       ├── apigee-environment.yaml
│           │       ├── components
│           │       │   ├── http-proxy
│           │       │   │   ├── kustomization.yaml
│           │       │   │   └── patch.yaml
│           │       │   ├── imagepullsecret
│           │       │   │   ├── kustomization.yaml
│           │       │   │   └── patch.yaml
│           │       │   ├── nodeselector
│           │       │   │   ├── kustomization.yaml
│           │       │   │   └── patch.yaml
│           │       │   └── workload-identity
│           │       │       ├── kustomization.yaml
│           │       │       ├── patch.yaml
│           │       │       └── service-accounts.yaml
│           │       ├── kustomization.yaml
│           │       └── secrets.yaml
│           ├── kustomization.yaml
│           ├── organization
│           │   ├── apigee-organization.yaml
│           │   ├── components
│           │   │   ├── http-proxy
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── imagepullsecret
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── nodeselector
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   └── workload-identity
│           │   │       ├── kustomization.yaml
│           │   │       ├── patch.yaml
│           │   │       └── service-accounts.yaml
│           │   ├── kustomization.yaml
│           │   └── secrets.yaml
│           ├── redis
│           │   ├── apigee-redis.yaml
│           │   ├── components
│           │   │   ├── imagepullsecret
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── nodeselector
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   └── workload-identity
│           │   │       ├── kustomization.yaml
│           │   │       ├── patch.yaml
│           │   │       └── service-accounts.yaml
│           │   ├── kustomization.yaml
│           │   └── secrets.yaml
│           ├── route-config
│           │   ├── kustomization.yaml
│           │   └── test-envgroup
│           │       ├── apigee-route-config.yaml
│           │       ├── components
│           │       │   ├── http-and-non-sni-client
│           │       │   │   ├── apigee-route.yaml
│           │       │   │   └── kustomization.yaml
│           │       │   ├── http-client
│           │       │   │   ├── apigee-route.yaml
│           │       │   │   └── kustomization.yaml
│           │       │   └── non-sni-client
│           │       │       ├── apigee-route.yaml
│           │       │       └── kustomization.yaml
│           │       └── kustomization.yaml
│           └── telemetry
│               ├── apigee-telemetry.yaml
│               ├── components
│               │   ├── http-proxy
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── imagepullsecret
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── logger
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── metrics
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── nodeselector
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── openshift-scc
│               │   │   ├── kustomization.yaml
│               │   │   └── scc.yaml
│               │   ├── workload-identity-logger
│               │   │   ├── kustomization.yaml
│               │   │   ├── patch.yaml
│               │   │   └── service-accounts.yaml
│               │   └── workload-identity-metrics
│               │       ├── kustomization.yaml
│               │       ├── patch.yaml
│               │       └── service-accounts.yaml
│               └── kustomization.yaml
├── README.md
├── templates
│   ├── certificate-org-envgroup.yaml
│   ├── secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml
│   ├── secret-apigee-cassandra-backup-and-restore-key-file.yaml
│   ├── secret-gcp-sa-key.yaml
│   └── secret-ingress-tls-cert-key.yaml
└── tools
    ├── apigee-hybrid-setup.sh
    ├── apigee-pull-push.sh
    ├── common.sh
    ├── create-service-account.sh
    └── dump_kubernetes.sh

Una versione dei file sopra menzionati è disponibile nel tag preview-1 del repository GitHub all'indirizzo: https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1.

La cartella sopra riportata contiene i manifest di Kubernetes per il runtime Apigee hybrid e utilizza Kustomize per la gestione della configurazione. I manifest sono organizzati in base al concetto di Personalizza basi e sovrapposizioni. La cartella bases contiene la configurazione minima necessaria per ogni componente di Apigee. La cartella overlays contiene diverse funzionalità aggiuntive(configurazioni) definite come componenti. È possibile creare un componente rimuovendo il commento dal riferimento al componente nel file kustomization.yaml.

Esempio : Per abilitare il gcs-backup per il datastore apigee, il componente gcs-backup è stato decommentato nel seguente customization.yaml.

Percorso : ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/kustomization.yaml

namespace: "apigee" # kpt-set: ${APIGEE_NAMESPACE}

resources:
- apigee-datastore.yaml

components:
# - ./components/http-proxy
# - ./components/nodeselector/
# - ./components/imagepullsecret
# - ./components/workload-identity
# - ./components/openshift-scc
- ./components/gcs-backup (uncommented)
# - ./components/gcs-restore
# - ./components/non-gcs-backup
# - ./components/non-gcs-restore

Qualsiasi valore che richieda personalizzazioni dovrà essere impostato nel file patch.yaml corrispondente per gcs-backup. Nel file sottostante, il valore di CLOUD_STORAGE_BUCKET_PATH deve essere impostato dall'utente

Percorso: $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/datastore/components/gcs-backup/cron-patch.yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: apigee-cassandra-backup
  namespace: apigee
spec:
  schedule: "${YOUR_BACKUP_SCHEDULE_CODE}" # To be modified
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: apigee-cassandra-backup
            env:
            - name: APIGEE_CLOUDPROVIDER
              value: "GCP"
            - name: DATABASE_STORAGE_BUCKET
              value: "${CLOUD_STORAGE_BUCKET_PATH}" # To be modified. REQUIRED
            volumeMounts:
            - name: apigee-cassandra-backup
              mountPath: /var/secrets/google
          volumes:
          - name: apigee-cassandra-backup
            secret:
              secretName: "apigee-cassandra-backup-and-restore-svc-account"

Allo stesso modo, qualsiasi funzionalità/configurazione che richieda personalizzazioni può essere abilitata rimuovendo il commento dal componente nel file kustomization.yaml del componente apigee. Inoltre, se necessario, i valori corrispondenti per i campi in patch.yaml del componente devono essere impostati di conseguenza.

Breve spiegazione delle cartelle e dei file:

basi

Questa cartella contiene i modelli con la configurazione minima richiesta da ciascuno dei componenti Apigee. Non sarebbe necessario apportare modifiche ai manifest in questa cartella.

sovrapposizioni

Questa cartella contiene i modelli dei componenti Kustomize per le configurazioni aggiuntive

inizializzazione

namespaces.yaml

Lo spazio dei nomi in cui verranno installati i componenti del piano dati di Apigee. Il nome dello spazio dei nomi predefinito è apigee

certificati

Contiene le risorse Issuer e Certificate utilizzate per emettere certificati per i webhook. Contiene inoltre il Issuer che viene utilizzato per rilasciare certificati a vari pod per la comunicazione TLS.

rbac

Contiene i valori Role, ClusterRole, RoleBinding e ClusterRoleBinding che verranno utilizzati da vari componenti.

crds

    Contains the definition of all the CRDs which are used by Apigee.

webhook

Contiene ValidatingWebhookConfiguration e MutatingWebhookConfiguration che verranno utilizzati per eseguire convalide sulle risorse personalizzate.

In entrata

Contiene la configurazione applicabile a tutti i POD di ingresso. Es. Modifiche comuni all'intestazione, controllo di integrità, ecc.

OpenShift

Contiene la definizione di SecurityContextConstraints di OpenShift.

Controller

controller apigee

apigee-hybrid-config.yaml

Contiene un ConfigMap che viene fornito come input in apigee-controller-manager.yaml. Questa ConfigMap contiene configurazioni come imageHub, imagePullSecrets, forwardProxy tra le altre cose.

apigee-controller-deployment.yaml

Contiene due servizi per il controller e il webhook, e il deployment per il controller. Se desideri utilizzare un'immagine privata per il controller, è qui che dovrai apportare la modifica.

istiodo

Apigee-istio-mesh-config.yaml Contiene la configurazione della mesh per Istio utilizzata da Apigee. Questa disposizione non si applica alle altre installazioni di ASM/Istio presenti nel cluster.

apigee-ingressgateway-manager-deployment-patch.yaml

Contiene un servizio e l'implementazione di Istiod. Questo è un istiod privato utilizzato esclusivamente per i casi d'uso di Apigee.

istanze/{nomeistanza}

datastore

apigee-datastore.yaml

Contiene la risorsa personalizzata ApigeeDatastore che gestisce Cassandra.

secrets.yaml

Contiene le credenziali predefinite per l'archivio dati.

redis

apigee-redis.yaml

Contiene la risorsa personalizzata ApigeeRedis che gestisce Redis.

secrets.yaml

Contiene le credenziali predefinite per l'archivio dati.

organizzazione

apigee-organization.yaml

Contiene la risorsa personalizzata ApigeeOrganization che gestisce altri sottocomponenti come connectAgent, watcherAndSynchronizer, MART,UDCA e Ingress.

secrets.yaml

Contiene gli Secret a cui si fa riferimento in apigee-organization.yaml. Alcuni segreti vengono commentati man mano che vengono generati dallo script. Se disabiliti la loro generazione, dovrai crearli manualmente

environments

Contiene tutto l'ambiente della tua organizzazione. È necessario creare una cartella separata per ogni ambiente copiando quella già fornita e configurandola in base alle esigenze.

dev

apigee-environment.yaml

Contiene la risorsa personalizzata ApigeeEnvironment che gestisce altri sottocomponenti come il runtime.

secrets.yaml

Contiene gli Secret a cui si fa riferimento in apigee-environment.yaml. Alcuni segreti vengono commentati man mano che vengono generati dallo script. Se disabiliti la loro generazione, dovrai crearli manualmente

telemetria

apigee-telemetry.yaml

Contiene la risorsa personalizzata ApigeeTelemetry.

secrets.yaml

Contiene gli Secret a cui si fa riferimento in apigee-telemetry.yaml. Alcuni segreti vengono commentati man mano che vengono generati dallo script. Se disabiliti la loro generazione, dovrai crearli manualmente

configurazione del percorso

dev-envgroup

apigee-route-config.yaml

Contiene la risorsa personalizzata ApigeeRouteConfig.

secrets.yaml

Contiene un Secret a cui si fa riferimento in apigee-route-config.yaml. È commentato perché viene generato automaticamente dallo script apigee-hybrid-setup.sh ed è presente solo per fornire un esempio di come dovrebbe apparire il segreto se lo si creasse manualmente.

diagnosi

diagnostic-collector.yaml

Risorse che verranno utilizzate per l'attivazione del deployment della diagnostica

strumenti

apigee-hybrid-setup.sh

apigee-create-service-account.sh

dump-kubernetes.sh

apigee-pull-push.sh

Archiviazione delle chiavi degli account di servizio in vault esterni

Vault (di Hashicorp) è un popolare sistema di gestione dei segreti che offre diverse integrazioni con i sistemi di archiviazione dei segreti forniti da Google, Azure, AWS e altri. HashiCorp Vault consente di recuperare segreti da una fonte esterna e di utilizzarli all'interno delle risorse Kubernetes. Esistono diversi modi in cui è possibile utilizzare Vault per reperire segreti. I seguenti passaggi serviranno da esempio di base su come utilizzare il Vault CSI Provider per montare le chiavi dell'account di servizio Google Cloud archiviate in un motore di segreti fornito da Vault.

---

Nota: In questo esempio, stiamo installando Vault in modalità di sviluppo a scopo di test. Per un sistema di produzione effettivo, ti consigliamo di installare Helm in una delle altre modalità elencate qui. Per istruzioni dettagliate sull'installazione di Vault per casi d'uso in produzione, fare riferimento alla Guida alla distribuzione di Vault su Kubernetes | Vault.

---

1. Utilizzeremo Helm per installare le risorse correlate a Vault nel cluster. Segui i passaggi descritti in Installazione di Helm per configurare Helm nel tuo sistema.

2. Segui i passaggi descritti in Installa il grafico Helm di Vault, ovvero:

   1. Aggiunta del repository Hashicorp a Helm

      helm repo add hashicorp https://helm.releases.hashicorp.com
      

   2. Aggiorna i repository Helm

      helm repo update
      

   3. Installazione di Vault

      helm install vault hashicorp/vault \
      --set "server.dev.enabled=true" \
      --set "injector.enabled=false" \
      --set "csi.enabled=true"
      

3. Ora memorizziamo il segreto in Vault.

   1. Recupera una shell all'interno del pod di sviluppo di Vault

      kubectl exec -it vault-0 -- /bin/sh
       ```
      

   2. In questo esempio utilizzeremo il motore di crittografia a chiave/valore per memorizzare i dati.

      vault kv put secret/runtime-gcp-sa-key key="${BASE_64_ENCODED_KEY}"
      

   3. Per verificare che la chiave sia stata memorizzata correttamente, utilizzare:

      vault kv get secret/runtime-gcp-sa-key
      

4. Configura l'autenticazione per consentire al pod di runtime di recuperare la chiave. Come discusso in Account di servizio Kubernetes, gli account di servizio Kubernetes forniscono un'identità ai pod e consentono loro di autenticarsi con altri sistemi.

   1. Ottieni una shell all'interno del pod di sviluppo del vault.

      kubectl exec -it vault-0 -- /bin/sh
      

   2. Abilita il metodo di autenticazione di Kubernetes

      vault auth enable kubernetes
      

   3. Scrivi la configurazione di autenticazione

      vault write auth/kubernetes/config \
      issuer="https://kubernetes.default.svc.cluster.local" \
      token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
      kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \
      kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
      disable_iss_validation=true
      

   4. creare la policy di autorizzazione

      vault policy write apigee-runtime-app - <<EOF
      path "secret/data/runtime-gcp-sa-key" {
      capabilities = ["read"]
      }
      EOF
      

   5. Associa la polizza all'account di servizio

      vault write auth/kubernetes/role/apigee-runtime-role \
      bound_service_account_names=apigee-runtime-sa \
      bound_service_account_namespaces=${APIGEE_NAMESPACE} \
      policies=apigee-runtime-app \
      ttl=20m
      

   In questo caso, si presume che l'account di servizio si trovi all'interno dello spazio dei nomi apigee. Se disponi di un altro namespace per l'installazione di apigee, utilizzerai quello.

   1. Esci dal guscio all'interno del vault-0

      exit
      

5. Installa il driver CSI per l'archivio segreti

   # Add repo to helm
   helm repo add secrets-store-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/secrets-store-csi-driver/master/charts
   # Install driver in cluster
   helm install csi secrets-store-csi-driver/secrets-store-csi-driver
   

6. Crea SecretProviderClass la risorsa Kubernetes che fa riferimento al segreto che hai creato all'interno di Vault

   cat > spc-vault.yaml <<EOF
   apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
   kind: SecretProviderClass
   metadata:
   name: vault-apigee-runtime-gcp-sa-key
   spec:
   provider: vault
   parameters:
     vaultAddress: "http://vault.default:8200"
     roleName: "apigee-runtime-role"
     objects: |
       - objectName: "client_secret.json"
         secretPath: "secret/data/runtime-gcp-sa-key"
         secretKey: "key"
   EOF
   

7. Applicare il yaml

   kubectl apply -f spc-vault.yaml
   

8. Crea l'account di servizio Kubernetes a cui abbiamo assegnato le autorizzazioni nel passaggio (4.e)

   kubectl create serviceaccount -n ${APIGEE_NAMESPACE} apigee-runtime-sa
   

9. Modifica il file apigee-environment.yaml per l'ambiente e aggiungi le seguenti righe:

   apiVersion: apigee.cloud.google.com/v1alpha2
   kind: ApigeeEnvironment
   # existing content
   spec:
   name: {ENV_NAME}
   organizationRef: {ORG_NAME}
   components:
    runtime:
   # existing content
      pod
      containers:
      - name: apigee-runtime
        podServiceAccountName: apigee-runtime-sa
   # existing content
        volumeMounts:
        - name: secrets-store-inline
          mountPath: "/opt/apigee/sa"
          readOnly: true
      volumes:
      - name: secrets-store-inline
        csi:
          driver: secrets-store.csi.k8s.io
          readOnly: true
          volumeAttributes:
            secretProviderClass: "vault-apigee-runtime-gcp-sa-key"
   

10. Applica le modifiche:

    kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/$ENV_NAME
    

Aggiornamento ibrido Apigee

---

Nota: - Questa procedura riguarda gli aggiornamenti tra versioni ibride che supportano il nuovo modello di installazione. Non copre la migrazione dall'esperienza apigeectl al nuovo modello di installazione.

---

È necessario aver completato tutti i requisiti menzionati in Prerequisiti. Inoltre, si consiglia di eseguire un riavvio progressivo di tutti i componenti per verificare lo stato di salute del cluster. L'ordine di riavvio sarà il seguente: Cassandra, Redis, ApigeeOrganization e ApigeeEnvironment.

Crea backup

1. Crea una copia di backup della configurazione ibrida corrente. Sarà necessario un backup nel caso in cui si renda necessario ripristinare la versione precedente dell'aggiornamento.

   tar -czvf apigee-hybrid-install.v-X.Y.Z.tar.gz $HYBRID_INSTALL_BASE_DIR
   

2. Creare un backup del database Cassandra. I backup di Cassandra rappresentano un'importante misura di protezione contro gli scenari di disastro.

Se necessario, aggiorna la tua piattaforma Kubernetes.

Questo passaggio non è sempre necessario, ma dovrai aggiornare la tua piattaforma Kubernetes, come Kubernetes, OpenShift e i relativi componenti come cert-manager, Cassandra, ecc., se non sono più supportati dalle versioni più recenti di Apigee Hybrid. La documentazione conterrà versioni supportate di piattaforme e componenti.

Scarica i file di installazione

Scarica il repository e sostituisci le cartelle bases e tools nella configurazione ibrida di Apigee esistente con una più recente:

1. Clona il tag preview-1 del repository GitHub in https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1

   Il repository clonato avrà una struttura simile a quella descritta in Struttura della cartella di configurazione ibrida di Apigee:

2. Sostituire le cartelle di inizializzazione, strumenti e controller nella configurazione ibrida di Apigee esistente.

   export HYBRID_INSTALL_HOME=PATH_TO_PREVIOUS_HYBRID_INSTALL_DIRECTORY
   mv -f bases $HYBRID_INSTALL_HOME/bases
   mv -f tools $HYBRID_INSTALL_HOME/tools
   

Aggiorna le autorizzazioni dell'account di servizio, se necessario.

Anche questo passaggio non è sempre necessario, ma se necessario dovrai creare un nuovo account di servizio o aggiornare le autorizzazioni degli account di servizio esistenti. La guida all'aggiornamento fornirà i dettagli su quali account di servizio devono essere modificati o creati e quali ruoli devono essere aggiunti.

• Se devi modificare le autorizzazioni degli account di servizio esistenti, usa il comando gcloud appropriato. La guida all'aggiornamento conterrà comandi dettagliati e i ruoli che devono essere aggiunti.

  gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-component@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/$NEW_ROLE"
  

• Se la versione ibrida più recente di Apigee dovesse richiedere un account di servizio aggiuntivo per i componenti nuovi / esistenti, sarà necessario crearli. È possibile utilizzare lo script apigee-create-service-account.sh incluso nella cartella degli strumenti per creare nuovi account di servizio. Poiché lo script verrà aggiornato come parte del passaggio 4, conterrà i dettagli e un nuovo profilo necessari per un nuovo account di servizio che deve essere creato.

  Il nome del account di servizio appena creato deve essere referenziato nel componente CR corrispondente.

  ./tools/create-service-account --env prod --profile apigee-component
  

Controller di aggiornamento

Modifica i campi della versione per i componenti elencati in ${INSTALL_DIR}/overlays/instances/$INSTANCE_DIR/kustomization.yaml con la versione ibrida pertinente.

Ecco un esempio di file $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/kustomization.yaml. Il valore del campo versione deve essere aggiornato alla versione pertinente

resources:
- datastore/
- environments/
- organization/
- redis/
- route-config/
- telemetry/

patches:
- target:
    group: apigee.cloud.google.com
    version: v1alpha1
    kind: ApigeeDatastore
  patch: |-
    - op: add
      path: /spec/version
      value: 1-6-1 (Modify the version)
- target:
    group: apigee.cloud.google.com
    version: v1alpha2
    kind: ApigeeEnvironment
  patch: |-
    - op: add
      path: /spec/version
      value: 1-6-1 (Modify the version)

Segui la stessa serie di passaggi forniti in Crea risorse di inizializzazione e controller nel flusso di lavoro di installazione ibrida di Apigee. Puoi utilizzare uno script o seguire i passaggi manuali forniti per aggiornare le risorse di inizializzazione e il controller.

Aggiorna i componenti di Apigee Kubernetes

Dovrai apportare le seguenti modifiche: - In caso di modifiche all'architettura o introduzione di nuovi campi o ritiro di campi precedenti, dovrai modificare le CR con le modifiche appropriate in base alle istruzioni fornite nella guida all'upgrade. - Come minimo, è necessario aggiornare i campi relativi alla versione all'interno delle CR (che indicheranno la versione di apigee hybrid installata) alla versione più recente di apigee hybrid.

Applica le modifiche per i CR apigee. Per gli ambienti non di produzione, è possibile applicare tutte le modifiche ai componenti di Apigee simultaneamente.

kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}

Apigee Hybrid Rollback

1. Ripristina la configurazione ibrida di apigee

   Spostarsi nella directory che contiene la versione precedente della configurazione ibrida di Apigee. Se non disponibile, ripristinalo dal file zip creato al passaggio 1[link] durante l'aggiornamento ibrido di Apigee.

2. Ripristino dei componenti di Kubernetes

   Applica le modifiche per le CR di apigee

   kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
   

3. controller di rollback

   Segui la stessa serie di passaggi forniti crea risorse di inizializzazione e controller nel flusso di lavoro di installazione ibrida di Apigee. Puoi utilizzare uno script o seguire i passaggi manuali forniti per ripristinare le risorse di inizializzazione e il controller.

4. Esegui la pulizia

   Dovrai liberare spazio da eventuali nuove risorse aggiuntive create durante l'upgrade, come nuovi componenti o service account introdotti nella versione più recente di ibrido. Nella guida all'aggiornamento saranno indicate tutte le risorse che devono essere ripulite e le procedure per farlo.

Eliminazione di un ambiente

---

Attenzione: Se si dispone di più ambienti, assicurarsi che i segreti che si stanno eliminando non siano referenziati negli altri ambienti. Per verificarlo, esegui kubectl get env -n ${APIGEE_NAMESPACE} ${ENV_RESOURCE_NAME} -o yaml e poi cerca la risorsa che intendi eliminare.

---

Di seguito sono riportati i passaggi per eliminare tutte le risorse relative a un ambiente dal cluster Kubernetes:

1. Ottieni il nome dell'ambiente CR. Ciò può essere fatto ottenendo tutti gli ambienti:

   kubectl get env -n ${APIGEE_NAMESPACE}
   

   Memorizza il nome della risorsa nella variabile di ambiente APIGEE_ENV.

2. Elimina le chiavi di crittografia dell'ambiente. Ad esempio, se non hai modificato il nome delle chiavi di crittografia, puoi eliminarle utilizzando:

   kubectl delete secret -n ${APIGEE_NAMESPACE} $APIGEE_ENV-encryption-keys
   

3. Elimina i secret del account di servizio Google Cloud:

   kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}')
   

4. Eliminare gli account di servizio di Kubernetes:

   kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')
   

5. Elimina la risorsa personalizzata dell'ambiente Apigee:

   kubectl -n ${APIGEE_NAMESPACE} delete env $APIGEE_ENV
   

Eliminazione di una configurazione ibrida

---

Attenzione: i passaggi verranno visualizzati in questo modo per la normale installazione di Apigee hybrid. I passaggi differiranno leggermente per i casi avanzati, ad esempio se è presente una seconda organizzazione all'interno dello stesso cluster e così via.

---

Di seguito sono riportati i passaggi per eliminare tutte le risorse relative ad Apigee Hybrid dal cluster Kubernetes:

1. Dovrai eliminare i job di configurazione degli utenti e degli schemi di Apigee.

   # To list all jobs in ${APIGEE_NAMESPACE}
   kubectl -n ${APIGEE_NAMESPACE} get jobs
   # To delete all jobs in ${APIGEE_NAMESPACE}
   kubectl -n ${APIGEE_NAMESPACE} delete jobs $(kubectl -n ${APIGEE_NAMESPACE} get jobs -o custom-columns=':.metadata.name')
   

2. Sarà necessario eliminare i componenti del piano dati ibrido di Apigee distribuiti. Utilizzare il seguente comando per eliminare tutti i componenti:

   kubectl delete -k ${INSTALL_DIR}/overlays/instances/$INSTANCE_NAME
   

3. Questo passaggio è necessario solo se non hai utilizzato il nome predefinito per i segreti dell'account di servizio Kubernetes, i segreti dell'account di servizio Google Cloud, ecc. Se hai utilizzato i nomi predefiniti, questi verranno eliminati nel passaggio successivo; in caso contrario, dovrai eliminarli manualmente utilizzando i seguenti comandi:

   kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get ${APIGEE_COMPONENT} ${APIGEE_COMPONENT_NAME} -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}')
   kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get ${APIGEE_COMPONENT} ${APIGEE_COMPONENT_NAME} -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')
   

4. Nel caso di OpenShift, sarà necessario eliminare gli scc (Security Context Constraints) creati durante l'installazione di Apigee Hybrid.

   kubectl delete scc ${SECURITY_CONTEXT_CONSTRAINTS_NAME}
   

5. Esegui il comando riportato di seguito per eliminare ruoli, rolebinding, CRD, deployment del controller e così via.

   kubectl delete -k ${INSTALL_DIR}/overlays/initialization/ingress
   kubectl delete -k ${INSTALL_DIR}/overlays/initialization/rbac
   kubectl delete -k ${INSTALL_DIR}/overlays/initialization/webhooks
   kubectl delete -k ${INSTALL_DIR}/overlays/initialization/crds
   kubectl delete -k ${INSTALL_DIR}/overlays/initialization/certificates
   

6. Esegui il comando riportato di seguito per eliminare lo spazio dei nomi apigee

   kubectl delete -f ${INSTALL_DIR}/overlays/initialization/namespace.yaml
   

   In alternativa, utilizzare il comando:

   kubectl delete $APIGEE_NAMESPACE
   

Installazione multi-istanza

La configurazione multi-istanza si riferisce alla configurazione ibrida che può estendersi su più regioni o anche all'interno della stessa regione. Apigee consiglia di organizzare le configurazioni della seconda istanza in una struttura di directory separata, poiché le configurazioni dell'ambiente (repliche, ecc.) sono invariabilmente diverse tra le istanze. Le configurazioni di ogni istanza sono disaccoppiate e organizzate in modo indipendente nelle rispettive strutture di cartelle.

Ad esempio, per una configurazione Attivo-Passivo in uno scenario multi-regione, potresti voler configurare una seconda regione in modalità standby a caldo con dimensioni e configurazioni diverse.

Nella struttura di cartelle riportata di seguito, è possibile creare una copia della directory instance1 denominata instance2 e modificare le configurazioni del datastore e dell'ingress secondo necessità.

apigee-hybrid-setup Struttura delle cartelle per la configurazione multi-istanza.]

.
├── bases
│   ├── controllers
│   │   ├── apigee-controller
│   │   │   ├── apigee-controller-deployment.yaml
│   │   │   └── kustomization.yaml
│   │   └── istiod
│   │       ├── apigee-ingressgateway-manager-deployment.yaml
│   │       └── kustomization.yaml
│   └── initialization
│       ├── certificates
│       │   ├── certificates-and-issuers.yaml
│       │   └── kustomization.yaml
│       ├── crds
│       │   ├── customresourcedefinition-apigeedatastores.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeedeployments.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeenvironments.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeredis.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeerouteconfigs.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeroutes.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeetelemetries.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-cassandradatareplications.apigee.cloud.google.com.yaml
│       │   └── kustomization.yaml
│       ├── ingress
│       │   ├── envoyfilter-1.11.yaml
│       │   └── kustomization.yaml
│       ├── openshift
│       │   ├── kustomization.yaml
│       │   └── scc.yaml
│       ├── rbac
│       │   ├── apigee-controller
│       │   │   ├── kustomization.yaml
│       │   │   └── rbac.yaml
│       │   └── apigee-embedded-ingress-controller
│       │       ├── cluster-role-bindings.yaml
│       │       ├── cluster-roles.yaml
│       │       ├── kustomization.yaml
│       │       └── service-account.yaml
│       └── webhooks
│           ├── kustomization.yaml
│           ├── mutatingwebhookconfiguration.yaml
│           └── validatingwebhookconfiguration.yaml
├── instances
│   └── instance1 (Add the 2nd instance under instances directory similar to instance1)
│       ├── datastore
│       │   ├── apigee-datastore.yaml
│       │   ├── components
│       │   │   ├── http-proxy
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   ├── imagepullsecret
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   ├── nodeselector
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   └── workload-identity
│       │   │       ├── apigee-workload-identities.yaml
│       │   │       ├── kustomization.yaml
│       │   │       └── patch.yaml
│       │   ├── kustomization.yaml
│       │   └── secrets.yaml
│       ├── environments
│       │   ├── kustomization.yaml
│       │   └── test
│       │       ├── apigee-environment.yaml
│       │       ├── components
│       │       │   ├── http-proxy
│       │       │   │   ├── kustomization.yaml
│       │       │   │   └── patch.yaml
│       │       │   ├── imagepullsecret
│       │       │   │   ├── kustomization.yaml
│       │       │   │   └── patch.yaml
│       │       │   ├── nodeselector
│       │       │   │   ├── kustomization.yaml
│       │       │   │   └── patch.yaml
│       │       │   └── workload-identity
│       │       │       ├── apigee-workload-identities.yaml
│       │       │       ├── kustomization.yaml
│       │       │       └── patch.yaml
│       │       ├── kustomization.yaml
│       │       └── secrets.yaml
│       ├── kustomization.yaml
│       ├── organization
│       │   ├── apigee-organization.yaml
│       │   ├── components
│       │   │   ├── http-proxy
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   ├── imagepullsecret
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   ├── nodeselector
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   └── workload-identity
│       │   │       ├── apigee-workload-identities.yaml
│       │   │       ├── kustomization.yaml
│       │   │       └── patch.yaml
│       │   ├── kustomization.yaml
│       │   └── secrets.yaml
│       ├── redis
│       │   ├── apigee-redis.yaml
│       │   ├── components
│       │   │   ├── imagepullsecret
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   ├── nodeselector
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   └── workload-identity
│       │   │       ├── apigee-workload-identities.yaml
│       │   │       ├── kustomization.yaml
│       │   │       └── patch.yaml
│       │   ├── kustomization.yaml
│       │   └── secrets.yaml
│       ├── route-config
│       │   ├── kustomization.yaml
│       │   └── test-env-group
│       │       ├── apigee-route-config.yaml
│       │       ├── components
│       │       │   ├── http-and-non-sni-client
│       │       │   │   ├── apigee-route.yaml
│       │       │   │   └── kustomization.yaml
│       │       │   ├── http-client
│       │       │   │   ├── apigee-route.yaml
│       │       │   │   └── kustomization.yaml
│       │       │   └── non-sni-client
│       │       │       ├── apigee-route.yaml
│       │       │       └── kustomization.yaml
│       │       └── kustomization.yaml
│       └── telemetry
│           ├── apigee-telemetry.yaml
│           ├── components
│           │   ├── http-proxy
│           │   │   ├── kustomization.yaml
│           │   │   └── patch.yaml
│           │   ├── imagepullsecret
│           │   │   ├── kustomization.yaml
│           │   │   └── patch.yaml
│           │   ├── logger
│           │   │   ├── kustomization.yaml
│           │   │   └── patch.yaml
│           │   ├── metrics
│           │   │   ├── kustomization.yaml
│           │   │   └── patch.yaml
│           │   ├── nodeselector
│           │   │   ├── kustomization.yaml
│           │   │   └── patch.yaml
│           │   ├── workload-identity-logger
│           │   │   ├── apigee-workload-identities.yaml
│           │   │   ├── kustomization.yaml
│           │   │   └── patch.yaml
│           │   └── workload-identity-metrics
│           │       ├── apigee-workload-identities.yaml
│           │       ├── kustomization.yaml
│           │       └── patch.yaml
│           └── kustomization.yaml
├── overlays
│   ├── controllers
│   │   ├── apigee-controller
│   │   │   ├── apigee-hybrid-config.yaml
│   │   │   ├── components
│   │   │   │   ├── imagepullsecret
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   └── patch.yaml
│   │   │   │   └── nodeselector
│   │   │   │       ├── kustomization.yaml
│   │   │   │       └── patch.yaml
│   │   │   └── kustomization.yaml
│   │   ├── istiod
│   │   │   ├── apigee-ingressgateway-manager-deployment-patch.yaml
│   │   │   ├── apigee-istio-mesh-config.yaml
│   │   │   ├── components
│   │   │   │   ├── imagepullsecret
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   └── patch.yaml
│   │   │   │   └── nodeselector
│   │   │   │       ├── kustomization.yaml
│   │   │   │       └── patch.yaml
│   │   │   └── kustomization.yaml
│   │   └── kustomization.yaml
│   ├── initialization
│   │   ├── certificates
│   │   │   ├── apigee-ingressgateway-manager-certificate.yaml
│   │   │   └── kustomization.yaml
│   │   ├── crds
│   │   │   └── kustomization.yaml
│   │   ├── ingress
│   │   │   └── kustomization.yaml
│   │   ├── namespace.yaml
│   │   ├── openshift
│   │   │   ├── kustomization.yaml
│   │   │   └── scc.yaml
│   │   ├── rbac
│   │   │   ├── apigee-controller
│   │   │   │   └── kustomization.yaml
│   │   │   ├── apigee-embedded-ingress-controller
│   │   │   │   └── kustomization.yaml
│   │   │   └── kustomization.yaml
│   │   └── webhooks
│   │       ├── kustomization.yaml
│   │       ├── mutatingwebhookconfiguration.yaml
│   │       └── validatingwebhookconfiguration.yaml
│   └── instances
│       └── instance1
│           ├── datastore
│           │   ├── apigee-datastore.yaml
│           │   ├── components
│           │   │   ├── http-proxy
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── imagepullsecret
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── nodeselector
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── openshift-scc
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── scc.yaml
│           │   │   └── workload-identity
│           │   │       ├── apigee-workload-identities.yaml
│           │   │       ├── kustomization.yaml
│           │   │       └── patch.yaml
│           │   ├── kustomization.yaml
│           │   └── secrets.yaml
│           ├── environments
│           │   ├── kustomization.yaml
│           │   └── test
│           │       ├── apigee-environment.yaml
│           │       ├── components
│           │       │   ├── http-proxy
│           │       │   │   ├── kustomization.yaml
│           │       │   │   └── patch.yaml
│           │       │   ├── imagepullsecret
│           │       │   │   ├── kustomization.yaml
│           │       │   │   └── patch.yaml
│           │       │   ├── nodeselector
│           │       │   │   ├── kustomization.yaml
│           │       │   │   └── patch.yaml
│           │       │   └── workload-identity
│           │       │       ├── apigee-workload-identities.yaml
│           │       │       ├── kustomization.yaml
│           │       │       └── patch.yaml
│           │       ├── kustomization.yaml
│           │       └── secrets.yaml
│           ├── kustomization.yaml
│           ├── organization
│           │   ├── apigee-organization.yaml
│           │   ├── components
│           │   │   ├── http-proxy
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── imagepullsecret
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── nodeselector
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   └── workload-identity
│           │   │       ├── apigee-workload-identities.yaml
│           │   │       ├── kustomization.yaml
│           │   │       └── patch.yaml
│           │   ├── kustomization.yaml
│           │   └── secrets.yaml
│           ├── redis
│           │   ├── apigee-redis.yaml
│           │   ├── components
│           │   │   ├── imagepullsecret
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── nodeselector
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   └── workload-identity
│           │   │       ├── apigee-workload-identities.yaml
│           │   │       ├── kustomization.yaml
│           │   │       └── patch.yaml
│           │   ├── kustomization.yaml
│           │   └── secrets.yaml
│           ├── route-config
│           │   ├── kustomization.yaml
│           │   └── test-envgroup
│           │       ├── apigee-route-config.yaml
│           │       ├── components
│           │       │   ├── http-and-non-sni-client
│           │       │   │   ├── apigee-route.yaml
│           │       │   │   └── kustomization.yaml
│           │       │   ├── http-client
│           │       │   │   ├── apigee-route.yaml
│           │       │   │   └── kustomization.yaml
│           │       │   └── non-sni-client
│           │       │       ├── apigee-route.yaml
│           │       │       └── kustomization.yaml
│           │       └── kustomization.yaml
│           └── telemetry
│               ├── apigee-telemetry.yaml
│               ├── components
│               │   ├── http-proxy
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── imagepullsecret
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── logger
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── metrics
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── nodeselector
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── openshift-scc
│               │   │   ├── kustomization.yaml
│               │   │   └── scc.yaml
│               │   ├── workload-identity-logger
│               │   │   ├── apigee-workload-identities.yaml
│               │   │   └── kustomization.yaml
│               │   └── workload-identity-metrics
│               │       ├── apigee-workload-identities.yaml
│               │       ├── kustomization.yaml
│               │       └── patch.yaml
│               └── kustomization.yaml
├── README.md
├── templates
│   ├── ingress-certificate.yaml
│   ├── ingress-cert-secret.yaml
│   └── service-account-key-secret.yaml
└── tools
    ├── apigee-hybrid-setup.sh
    ├── common.sh
    ├── create-service-account.sh
    └── dump_kubernetes.sh

Configurazione multi-istanza su GKE

Prerequisiti

Prima di configurare più istanze di Hybrid, è necessario aver completato i seguenti prerequisiti:

• Configura cluster Kubernetes in più regioni(uguali o diverse) con blocchi CIDR differenti
• Configurare la comunicazione tra regioni
• Apri le porte 7000 e 7001 di Cassandra tra i cluster Kubernetes in tutte le regioni (la porta 7000 può essere utilizzata come opzione di backup durante la risoluzione dei problemi). Vedi anche Configurare le porte.

---

Nota: Apigee consiglia di assicurarsi che gli orari dei server siano sincronizzati. Diverse funzionalità, come la scadenza e la revoca dei token, dipendono da orari di sistema precisi. Se i componenti runtime sono ospitati in data center diversi, assicurarsi che gli orari di sistema siano sincronizzati.

È possibile utilizzare uno strumento come ntpdate per verificare che gli orari del server siano sincronizzati.

---

Configura l'host seed multiregionale

1. Crea una copia della cartella $INSTANCE_NAME dall'istanza esistente e aggiungila alla cartella delle istanze.
2. Modifica il valore del campo namespace se è diverso da quello del namespace instance1.
3. Segui i passaggi specificati in Specificare i certificati TLS in ingresso per modificare la configurazione in ingresso per l'altra istanza.

4. Consultare Gestione del gateway di ingresso Apigee per informazioni sulla configurazione dell'IP del bilanciatore di carico per l'altra istanza

   ---

   Nota: Si raccomanda di non modificare le configurazioni degli altri componenti, ad eccezione di quelli elencati nei passaggi successivi.

   ---

5. Imposta il contesto kubectl sul cluster originale prima di recuperare il nome del seed.

   kubectl config use-context original-cluster-name
   

6. Eseguire il seguente comando kubectl per identificare un indirizzo host seed per Cassandra nella regione corrente.

   kubectl get pods -o wide -n apigee -l app=apigee-cassandra
   

7. Ciascuno degli indirizzi IP dei Pod restituiti dal comando precedente può essere considerato come host seed multi-regione.

8. Nella seconda istanza, configura il valore di multiRegionSeedHost nel CR del datastore apigee in ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/apigee-datastore.yaml

Configura la nuova istanza

1. Imposta il contesto sul cluster esistente

   kubectl config use-context existing-cluster-name
   

2. Esporta il segreto apigee-ca in un file

   kubectl -n cert-manager get secret apigee-root-certificate -o yaml > apigee-root-certificate.yaml
   

3. Imposta il contesto sul nome del cluster della nuova regione:

   kubectl config use-context NEW_CLUSTER_NAME
   

4. Importa il segreto nel nuovo cluster

   kubectl -n cert-manager apply -f apigee-root-certificate.yaml
   

5. Installa ibrido nella nuova istanza (regione) seguendo i passaggi descritti in Crea risorse di inizializzazione e controller.

6. Configura Cassandra su tutti i pod nei nuovi data center. Scarica apigeeorg dal cluster con il seguente comando:

   kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"
   

7. Crea un file di risorsa personalizzata (YAML) di replica dei dati Cassandra. Il file può avere qualsiasi nome. Negli esempi seguenti il ​​file avrà il nome datareplication.yaml. Il file deve contenere quanto segue

   apiVersion: apigee.cloud.google.com/v1alpha1
   kind: CassandraDataReplication
   metadata:
   name: REGION_EXPANSION
   namespace: NAMESPACE
   spec:
   organizationRef: APIGEEORG_VALUE
   force: false
   source:
     region: SOURCE_REGION
   

   Dove:

   • REGION_EXPANSION è il nome che stai assegnando a questi metadati. È possibile scegliere un nome come "cassandra-data-replication"
   • NAMESPACE è lo stesso namespace che è stato scelto per la seconda istanza. Solitamente si tratta di "apigeo".
   • APIGEEORG_VALUE è il valore restituito dal comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" eseguito nel passaggio precedente.
   • SOURCE_REGION è il valore del datacenter di cassandra dallo stato di nodetool dal cluster sorgente.

8. Applicare CassandraDataReplication con il seguente comando:

   kubectl apply -f datareplication.yaml
   

9. Verifica lo stato della ricompilazione utilizzando il seguente comando.

   ---

   Nota: L'operazione di ricostruzione può richiedere fino a diverse ore a seconda delle dimensioni dei dati.

   ---

   kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
   

   Il risultato dovrebbe essere qualcosa del genere

   {
   "rebuildDetails": {
     "apigee-cassandra-default-0": {
       "state": "complete",
       "updated": 1623105760
     },
     "apigee-cassandra-default-1": {
       "state": "complete",
       "updated": 1623105765
     },
     "apigee-cassandra-default-2": {
       "state": "complete",
       "updated": 1623105770
     }
   },
   "state": "complete",
   "updated": 1623105770
   }
   

10. Verifica i processi di ricompilazione dai log. Inoltre, verifica la dimensione dei dati utilizzando il comando nodetool status:

    kubectl logs apigee-cassandra-default-0 -f -n apigee
    

    Consultare il file datastore/secrets.yaml per i valori di JMX_user e JMX_password.

    kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status
    

11. Rimuovere multiRegionSeedHost dal CR del datastore apigee ed eseguire il comando seguente per applicare la modifica

    kubectl apply k apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore
    

12. Controlla lo stato del cluster Cassandra

    Il seguente comando è utile per verificare se la configurazione del cluster è andata a buon fine in due data center. Il comando controlla lo stato di nodetool per le due regioni.

    kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status
    
    

    Datacenter: us-central1
    =======================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
    UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
    UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
    Datacenter: us-west1
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  10.0.4.33   78.69 KiB  256          100.0%               a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
    UN  10.0.0.21   78.68 KiB  256          100.0%               9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
    UN  10.0.1.26   15.46 KiB  256          100.0%               1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1
    

Risoluzione dei problemi

Guida alla compatibilità, alla diagnosi e alla risoluzione dei problemi

https://cloud.google.com/apigee/docs/api-platform/troubleshoot/playbooks/troubleshooting-apigee-hybrid.

Pulizia manuale dopo l'utilizzo di forceDelete in una configurazione ibrida Apigee multi-regione.

• Nell'esempio seguente, ci sono 2 regioni: us-east1 e us-west1.
• Nella regione us-west1, il datastore apigee è stato eliminato tramite eliminazione forzata.
• Nella regione us-east1, Cassandra è ancora attiva e funzionante.

• Verificare che apigeeds sia stato eliminato utilizzando il comando

  kubectl get apigeeds -n apigee
  No resources found in apigee namespace.
  

• Cambia il contesto di kubectl nell'altra regione in cui il cluster Cassandra è ancora attivo e funzionante (in questo caso la regione us-east1).

• Verificare che il datastore sia in stato di esecuzione

  kubectl get apigeeds -n apigee
  NAME      STATE     AGE
  default      running    23h
  

• Eseguire in uno dei baccelli di cassandra nella regione superiore (qui la regione us-east1)

  kubectl exec -it -n apigee apigee-cassandra-default-0 -- bash
  apigee@apigee-cassandra-default-0:~$
  

• Controlla lo stato di nodetool, mostrerà tutti i nodi non funzionanti nella regione eliminata (qui us-west1)

  apigee@apigee-cassandra-default-0:~$ nodetool -u ${APIGEE_JMX_USER} -pw ${APIGEE_JMX_PASSWORD} status
  

  Datacenter: us-east1
  ====================
  Status=Up/Down
  |/ State=Normal/Leaving/Joining/Moving
  --     Address         Load           Tokens   Owns    Host ID                                                           Rack
  UN  10.52.0.212   685.01 KiB  256          ?         e1aa61e3-4eae-4549-9b58-506d495d87ab   ra-1
  UN  10.52.0.72     606.75 KiB  256          ?         477dfc03-f93e-40ea-810a-d15769822ad5     ra-1
  UN  10.52.0.104   648.3 KiB    256          ?         a8854cff-c2e3-4f0c-a342-e692787efcab        ra-1
  Datacenter: us-west1
  ====================
  Status=Up/Down
  |/ State=Normal/Leaving/Joining/Moving
  --     Address         Load             Tokens   Owns     Host ID                                                           Rack
  DN  10.60.0.143   567.06 KiB    256          ?           355d6ace-ab77-42cb-8138-9993bfd62d0e    ra-1
  DN  10.60.0.40     535.99 KiB    256          ?           4ed2c903-ff56-40fa-a15e-80a3de3cb22d      ra-1
  DN  10.60.0.17     573.08 KiB    256          ?           f9a50d19-c04a-4d0d-a088-612384bed9f5     ra-1
  

• Rimuovi tutti i nodi nella regione eliminata (qui us-west1)

  apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode 355d6ace-ab77-42cb-8138-9993bfd62d0e
  apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode 4ed2c903-ff56-40fa-a15e-80a3de3cb22d
  apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode f9a50d19-c04a-4d0d-a088-612384bed9f5
  

• Verificare che non rimangano nodi della regione eliminata (qui us-west1).

  apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status
  
  

  Datacenter: us-east1
  ====================
  Status=Up/Down
  |/ State=Normal/Leaving/Joining/Moving
  --     Address         Load             Tokens  Owns   Host ID                                                           Rack
  UN  10.52.0.212   699.71 KiB    256          ?        e1aa61e3-4eae-4549-9b58-506d495d87ab  ra-1
  UN  10.52.0.72     586.77 KiB    256          ?        477dfc03-f93e-40ea-810a-d15769822ad5    ra-1
  UN  10.52.0.104   623.6 KiB      256          ?        a8854cff-c2e3-4f0c-a342-e692787efcab       ra-1
  

• Una volta completata questa operazione, eliminare il job di configurazione utente nella regione superiore (qui us-east1). Il job verrà ricreato automaticamente entro pochi secondi.

  kubectl get jobs -n apigee
  
  

  ​​NAME                                                                                    COMPLETIONS   DURATION   AGE
  apigee-cassandra-schema-setup-apigee--0d2504c                    0/1           5m54s      5m54s
  apigee-cassandra-user-setup--apigee--0d2504c                          0/1            7s         7s
  
  

  kubectl delete job apigee-cassandra-user-setup--apigee--0d2504c
  

• Attendi il completamento della procedura di configurazione utente.

  kubectl get jobs -n apigee
  

  ​​NAME                                                                                    COMPLETIONS   DURATION   AGE
  apigee-cassandra-schema-setup-apigee--0d2504c                    1/1           5m54s      5m54s
  apigee-cassandra-user-setup--apigee--0d2504c                      1/1           7m                7m
  

• Verificare che gli spazi chiave non contengano la regione eliminata.

• Crea un pod di debug di Cassandra.

  • Segui la versione ibrida 1.5+, segui la documentazione della guida alla risoluzione dei problemi di Cassandra (ad esempio per ibrida 1.5 - link, ibrida 1.6 - link) e poi esegui il pod creato

• Accedi a cqlsh nel pod di debug utilizzando il comando

  apigee@cassandra-debug-client:~$ cqlsh apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local -u ddl_user --ssl
  Password:
  

• Verificare che la regione us-west1 sia stata rimossa da tutti gli spazi chiave.

  ddl_user@cqlsh> SELECT * FROM system_schema.keyspaces;
  

  keyspace_name              | durable_writes | replication
  ---------------------------+----------------+-----------------------------------------------------------------------------------
  cache_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
    rtc_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
                  system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
                system_schema |           True |                            {'class': 'org.apache.cassandra.locator.LocalStrategy'}
  quota_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
    kms_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
           system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
                       system |           True |                            {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                       perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
    kvm_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
                system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
  (11 rows)