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

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

In questo documento:

Anteprima

Questo documento è destinato alla persona dell'operatore Apigee (utenti che installano/gestiscono/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. Ti consigliamo di creare un'organizzazione Apigee di valutazione per provare i passaggi riportati di seguito.

Feedback

Invia un feedback su questa procedura all'indirizzo Apigee-hybrid-install-preview@google.com.

Panoramica

La nuova esperienza di installazione di Apigee Hybrid installa i componenti Apigee utilizzando kubectl e integra l'installazione e la gestione di Apigee Hybrid con strumenti di orchestrazione della configurazione 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 gli strumenti CI/CD Kubernetes esistenti come Argo, Flux o Anthos Config Management, che non utilizzano un file di configurazione overrides.yaml.
  • 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 service account con le autorizzazioni richieste, certificati TLS, precompilando i valori predefiniti e altri elementi di base necessari.

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
  2. Configurazione del runtime di hybrid

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 riportate in Get Docker per installare Docker.
  • envsubst dovrebbe essere disponibile nella maggior parte dei sistemi basati su Linux/UNIX. Per macOS e altri sistemi, segui le istruzioni riportate in questo repository.
  • jq deve essere installato. Scarica jq.

  • kpt Scarica kpt.

  • kubectl versione 1.23 o successive. Consulta la sezione Install Tools: kubectl nella documentazione di Kubernetes.

Variabili comuni utilizzate in questa guida

Questa guida utilizza le seguenti variabili di ambiente in diversi passaggi. Puoi definirli nella riga di comando o con uno script oppure puoi sostituire il testo nei comandi quando li inserisci.

  • APIGEE_NAMESPACE: il tuo spazio dei nomi Apigee. Per impostazione predefinita, questo valore è apigee. Tuttavia, puoi 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 in 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. Puoi 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. Puoi creare più gruppi di ambienti.
  • INSTALL_DIR: la directory in cui installi Apigee hybrid. Per impostazione predefinita, si tratta della sottodirectory apigee-hybrid-install/ della directory in cui scarichi il programma di installazione, ad esempio: /myhybrid/apigee-hybrid-install/. Questa è la directory principale per la struttura dei file documentata in Struttura delle cartelle di configurazione di Apigee Hybrid.
  • INSTANCE_DIR: la directory per un'istanza Apigee hybrid specifica. Per impostazione predefinita, la prima istanza si chiama instance-1. La directory dell'istanza è una sottodirectory di ${INSTALL_DIR}/overlays/instances/. Puoi specificare qualsiasi nome per le istanze ibride. Consulta la sezione Installazione di più istanze.
  • ORG_NAME: il nome della tua organizzazione Apigee hybrid. Deve essere uguale all'ID progetto Google Cloud. Vedi: Passaggio 2: crea un'organizzazione.

Installazione di base di Apigee hybrid

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

  • Un unico ambiente
  • 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. Scaricare i file di configurazione
  2. Esegui configurazione

Scaricare i file di configurazione

Scarica e prepara i file di configurazione 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. Vai 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:

Esegui configurazione

Esegui lo script shell apigee-hybrid-setup.sh che si trova nella cartella tools/.

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

Se riscontri 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 che hai 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 nell'output standard.

Una volta completato correttamente lo script, l'installazione ibrida di base sarà terminata. Puoi testare l'installazione creando un proxy di esempio come descritto in Creazione e deployment di un nuovo proxy API.

Installazione personalizzata di Apigee Hybrid

Gli utenti più esperti che desiderano un controllo granulare sull'installazione possono seguire questa sequenza di passaggi (per molti dei passaggi riportati di seguito, puoi scegliere di eseguire il passaggio manualmente o utilizzare lo script shell per automatizzare il singolo passaggio):

Scaricare i file di configurazione

Scarica e prepara i file di configurazione:

  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. cd nella directory apigee-hybrid-install/

  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

Se scegli un altro nome per lo spazio dei nomi, puoi scegliere di seguire una delle tre opzioni riportate di seguito:

  • (Consigliato) Utilizza --namespace={YOUR_NAMESPACE_NAME} durante il precompilamento dei valori in Modifica i file YAML delle risorse.

  • Esegui questi due comandi:

    1. Utilizza 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. Utilizza sed per sostituire lo spazio dei nomi 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, puoi modificare manualmente le risorse singolarmente per crearle nello spazio dei nomi che preferisci.

Utilizzo di immagini Docker da repository privati (facoltativo)

Puoi scegliere di non utilizzare le immagini ospitate pubblicamente e utilizzare immagini dei tuoi repository privati:

  1. Il primo passaggio consiste nel eseguire il push di tutte le immagini nel repository privato, il che può essere fatto seguendo i passaggi descritti in apigee-pull-push | Apigee X. Per impostazione predefinita, le immagini vengono taggate con la versione di Apigee Hybrid a cui corrispondono ed è consigliabile non modificare questi tag. Ti consigliamo inoltre di non modificare i nomi delle immagini in modo che il percorso finale dell'immagine possa essere creato 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 maggiori dettagli, consulta l'hub delle immagini.

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

In questo modo, tutti i componenti di Apigee Hybrid utilizzano le immagini del tuo repository privato.

Oltre a questo, potresti anche voler utilizzare un'immagine privata per il controller e il gateway in entrata Apigee, per i quali dovrai modificare i file apigee-controller-deployment.yaml e apigee-ingressgateway-manager-deployment.yaml e sostituire tutti i campi image con l'immagine del repository privato.

Configurazione di imagePullSecrets (facoltativa)

  1. Crea un secret di Kubernetes contenente le credenziali per l'autenticazione con i repository privati. Consulta Recuperare un'immagine da un registro privato per capire come deve essere creato il secret.
  2. Una volta creato il secret, non resta che farvi riferimento. Per farlo, modifica il file apigee-hybrid-config.yaml, imposta il valore del campo imagePullSecret sul nome del secret creato in precedenza e attiva il componente imagePullSecret nel file kustomization.yaml corrispondente.

Se specifichi imagePullSecrets in entrambi i punti, avrà la precedenza quello presente nel file apigee-controller-manager.yaml.

(Facoltativo) Configurazione del proxy di inoltro

I proxy di inoltro possono essere configurati 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 entrata

Utilizzare lo script

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

Refer - Understanding the script per ulteriori dettagli su questo flag.

Manuale

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

Qui utilizzeremo i certificati autofirmati come esempio. I certificati autofirmati possono essere generati utilizzando (supponendo che DOMAIN sia stato impostato correttamente e corrisponda al nome host impostato nel tuo gruppo di ambienti):

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

Verranno creati due file denominati tls.key e tls.crt.

Devi quindi creare un secret con il seguente formato. Puoi utilizzare kubectl create o kubectl apply come spiegato in Utilizzo di una coppia di 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 secret utilizzando kubectl create:

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

Aggiorna il deployment di Ingress

Per creare/modificare i deployment Ingress, devi 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 un deployment in entrata con parametri predefiniti(i valori predefiniti verranno visualizzati nella documentazione di riferimento CR ):

ingressGateways:
- name: "prod-1"

Esempi:

A. Override dei campi del servizio di ingresso

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

B. Modifica il numero minimo/massimo di repliche

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

C. Aggiunta di un nuovo deployment Ingress

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

Configurazione di service account Google Cloud personalizzati

Utilizzare lo script

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

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

Per ulteriori dettagli sui flag, consulta la sezione Informazioni sullo script.

Manuale

Le chiavi del account di servizio Google Cloud devono essere archiviate come secret nel cluster. Il file YAML del secret deve 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 ulteriori dettagli su tutti i service account richiesti e sui nomi dei secret, consulta la sezione Service account Google Cloud.

Puoi scegliere un nome diverso per i secret, ma dovrai apportare una modifica corrispondente nel componente in cui è stato utilizzato il nome del secret. Ad esempio, se decidi di modificare il nome del secret del account di servizio di runtime da apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME} a my-runtime-svc, dovrai apportare una modifica corrispondente in apigee-environment.yaml per quell'ambiente.

Utilizzo delle identità dei carichi di lavoro

Una delle due opzioni, Configurazione di service account Google Cloud personalizzati o Utilizzo delle identità del carico di lavoro, è obbligatoria.

Prerequisiti

Prima di utilizzare le identità del workload, assicurati che il supporto sia abilitato nel tuo cluster GKE. Per maggiori dettagli, consulta Aggiornamento dei pool di nodi | Apigee X.

Abilitazione di workload-identity

Per informazioni dettagliate su come abilitare le identità dei workload prima dell'installazione, consulta la sezione Identità dei workload in Kustomize e componenti.

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.

Utilizzare lo script

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

Crea risorse di inizializzazione e 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

Concedi le autorizzazioni al account di servizio di Synchronizer per interagire con il control plane

Segui i passaggi descritti in Passaggio 8: attiva l'accesso al sincronizzatore, sostituendo il nome dell'account di servizio, apigee-non-prod o apigee-synchronizer, con apigee-all-sa, il nome dell'account di servizio creato dalla nuova procedura di installazione.

★ Importante: assicurati di modificare il nome del account di servizio nelle istruzioni riportate in Attivare l'accesso al sincronizzatore. In caso contrario, l'attivazione dell'accesso per il sincronizzatore non andrà a buon fine.

Crea i componenti del piano dati 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 viene eseguito cert-manager con la seguente procedura.

Se cert-manager è installato nel cluster in uno spazio dei nomi diverso da cert-manager, dovrai aggiornare lo spazio dei nomi utilizzato per creare il certificato radice 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.

Kustomize e componenti

Panoramica

La nuova installazione ibrida eredita l'ideologia di Kustomize di strutturare i file YAML sotto forma di basi e overlay.

  • Le basi sono file forniti da Apigee, che potrebbero cambiare a ogni nuova release di Hybrid. 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 per modificare i valori predefiniti specificati nelle basi. Tutti i file nella cartella di primo livello overlays/ contengono queste sovrapposizioni

Come utilizzare i componenti

Le sottocartelle all'interno della directory overlays/ di primo livello sono state strutturate in modo tale da poter attivare (o disattivare) una determinata funzionalità aggiuntiva commentando (o decommentando) alcune righe nei file kustomization.yaml.

Ad esempio, ecco come appare 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 si presenterebbero probabilmente 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

Ci risulta 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

Allo stesso modo, per disattivare le metriche, puoi commentare la riga ./components/metrics:

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

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

OpenShift

Per gli utenti che vogliono installare Apigee Hybrid in un cluster OpenShift, potrebbe essere necessario abilitare alcuni componenti/risorse prima di eseguire l'installazione. Questo passaggio è obbligatorio se non utilizzi lo script per eseguire l'installazione. I file da modificare sono:

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

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

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

    # - ./components/openshift-scc

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

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

    # - ./components/openshift-scc

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

A questo punto puoi procedere con i passaggi di installazione.

imagepullsecret

Questo componente può essere abilitato quando hai immagini archiviate nel tuo repository privato. Per eseguire il pull delle immagini da un repository privato, puoi creare un secret Kubernetes che contenga i dettagli di autenticazione e a cui puoi fare riferimento all'interno. Per le istruzioni, vedi Configurazione di imagePullSecrets (facoltativo). Per ulteriori informazioni, consulta Pull an Image from a Private Registry | Kubernetes nella documentazione di Kubernetes.

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

Attivazione in corso:

Rimuovi il commento dalla riga "./components/imagepullsecret/" nei rispettivi file kustomization.yaml, se necessario.

Modifiche da apportare:

  • components/imagepullsecret/patch.yaml
    • OBBLIGATORIO Aggiungi i nomi dei 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 durante la procedura

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

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

nodeselector

Questo componente ti consente di pianificare i pod per una risorsa Apigee su nodi specifici. Per ulteriori informazioni, consulta Assegnazione di pod ai nodi | Kubernetes.

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

Attivazione in corso:

Rimuovi il commento dalla riga "./components/nodeselector" nei rispettivi file kustomization.yaml, se necessario.

Modifiche da apportare:

  • components/nodeselector/patch.yaml
    • (FACOLTATIVO) Modifica il valore dell'etichetta del selettore di nodi 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 durante la procedura

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

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

workload-identity

Diversi container nell'ecosistema Apigee Hybrid richiedono autorizzazioni per effettuare determinate chiamate API al control plane / management plane di Apigee. Workload Identity è uno dei modi per concedere queste autorizzazioni ai pod (e ai container al loro interno). Ecco alcune risorse utili per saperne di più: - Introducing Workload Identity: Better authentication for your GKE applications | Google Cloud Blog - Use Workload Identity | Kubernetes Engine Documentation | 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. Di solito è apigee, a meno che non sia stato modificato esplicitamente dall'utente durante l'installazione - ${KSA_NAME} - Il nome dello spazio dei nomi Kubernetes. Devi eseguire questo comando per ogni account di servizio Kubernetes menzionato in Service account Kubernetes - ${GSA_NAME} - Il nome del account di servizio Google Cloud. Se non hai apportato modifiche durante l'installazione, questo valore sarà apigee-all-sa. Se configuri più account di servizio Google Cloud per singoli componenti, devi abbinare KSA_NAME al GSA_NAME corrispondente. Puoi confrontare le tabelle in Service account Google Cloud con Service account Kubernetes per trovare gli equivalenti.

Attivazione in corso:

Rimuovi il commento dalla riga ./components/workload-identity nei rispettivi file kustomization.yaml, se necessario. Tieni presente che all'interno della telemetria sono presenti componenti aggiuntivi di identità del workload separati per i componenti metrics e logger, che possono essere attivati singolarmente.

Utilizzo:

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

  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

Attivazione in corso:

Rimuovi il commento dalla riga "./components/http-proxy/" nei rispettivi file kustomization.yaml, se necessario.

Modifiche da apportare:

  • components/http-proxy/patch.yaml I seguenti parametri possono essere configurati in spec.httpForwardProxy
    • scheme: OBBLIGATORIO. Uno tra HTTP o HTTPS
    • host: OBBLIGATORIO L'indirizzo host del proxy
    • port: OBBLIGATORIO Il numero di porta
    • username: FACOLTATIVO Il nome utente associato al 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 durante la procedura

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

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

logger e metriche

Puoi attivare o disattivare singolarmente il logger o le metriche all'interno di sovrapposizioni/istanze/{INSTANCE_NAME}/telemetria. Per impostazione predefinita, il logger è disattivato e le metriche sono attivate. Per attivarli o disattivarli, è sufficiente rimuovere il commento o aggiungere un commento alle righe in telemetry/kustomization.yaml

gcs-backup e gcs-restore

Questo componente kustomize può essere utilizzato per eseguire un backup e un ripristino del database Cassandra in Google Cloud Storage.

Disponibile in:

  • overlays/instances/{INSTANCE_NAME}/datastore

Prerequisito:

  1. Scarica le chiavi dei service account Google Cloud per un account con il ruolo Amministratore oggetti Storage.

    • Se hai utilizzato lo script per eseguire l'installazione e non hai utilizzato workload identity, 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, devi creare un secret Kubernetes con il nome apigee-cassandra-backup-and-restore-gcp-sa-key, che può essere creato 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 Apigee. Di solito è apigee, a meno che non sia stato modificato esplicitamente durante l'installazione

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

Attivazione in corso:

  • Se vuoi attivare il backup, rimuovi il commento dalla riga "./components/gcs-backup" nel file datastore kustomization.yaml.
  • Se vuoi ripristinare un backup, rimuovi il commento dalla riga "./components/gcs-restore" nel file datastore kustomization.yaml.

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 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 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.
    • (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

Puoi eseguire il backup con il seguente comando:

kubectl apply -k overlays/instances/{INSTANCE_NAME}

Per applicare le modifiche e attivare il backup:

Modifiche solo per il ripristino

  • components/gcs-restore/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-restore/job-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.
    • REQUIRED Modifica il valore della variabile di ambiente BACKUP_SNAPSHOT_TIMESTAMP. La descrizione corrisponde al ripristino: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, vedi Ripristino dei backup | Apigee X | Google Cloud

  1. Crea un nuovo cluster Kubernetes con un nuovo spazio dei nomi in cui ripristinare il deployment dell'ambiente di runtime ibrido. Non puoi utilizzare lo stesso cluster e lo stesso spazio dei nomi che hai utilizzato 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}

  3. Una volta completato il ripristino, tutte le risorse nel vecchio spazio dei nomi possono essere eliminate e trasferite al nuovo spazio dei nomi.

Per ulteriori informazioni, vedi Ripristinare i backup.

non-gcs-backup e non-gcs-restore

Questo componente kustomize può essere utilizzato per eseguire un backup e un ripristino del database Cassandra in Google Cloud Storage.

Disponibile in:

  • overlays/instances/{INSTANCE_NAME}/datastore

Prerequisito:

  1. È possibile utilizzare i passaggi della documentazione già esistente 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.

    Il secret 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 Apigee. Di solito è apigee, a meno che non sia stato modificato esplicitamente 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 vuoi attivare il backup, rimuovi il commento dalla riga "./components/non-gcs-backup" nel file datastore kustomization.yaml.
  • Se vuoi ripristinare un backup, rimuovi il commento dalla riga "./components/non-gcs-restore" nel file datastore kustomization.yaml.

Modifiche solo per il backup

  • components/non-gcs-backup/apigee-datastore-patch.yaml
    • 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 descritto 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 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 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

Puoi eseguire il backup con il seguente comando:

kubectl apply -k overlays/instances/{INSTANCE_NAME}

Per applicare le modifiche e attivare 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 descritto qui.
    • OBBLIGATORIO Modifica 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 descritto qui.
    • REQUIRED Modifica il valore di BACKUP_SERVER_IP. La descrizione corrisponde a BACKUP_SERVER_IP descritto qui.
    • REQUIRED Modifica il valore di BACKUP_STORAGE_DIR. La descrizione corrisponde a BACKUP_STORAGE_DIR 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 una panoramica del ripristino dei backup, consulta Panoramica del ripristino di Cassandra.

  1. Crea un nuovo cluster Kubernetes con un nuovo spazio dei nomi in cui ripristinare il deployment dell'ambiente di runtime ibrido. Non puoi utilizzare lo stesso cluster e lo stesso spazio dei nomi che hai utilizzato 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 nel vecchio spazio dei nomi possono essere eliminate e trasferite al nuovo spazio dei nomi.

    Per ulteriori informazioni, vedi Pianificare i 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}

Attivazione in corso:

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

Modifiche da apportare:

  • Non sono richieste modifiche obbligatorie.

Utilizzo:

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

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

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

non-sni-client

Equivalente alla How to configure a non-SNI client | Apigee esistente.

Disponibile in:

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

Attivazione in corso:

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
    • OBBLIGATORIO credentialName La descrizione corrisponde a quella credential_name descritta qui.

Utilizzo:

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

  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 istruzioni, vedi Abilitare il supporto per client non SNI e HTTP | Apigee.

Attivazione in corso:

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
    • OBBLIGATORIO credentialName La descrizione corrisponde a quella credential_name descritta qui.

Utilizzo:

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

  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 datacenter Cassandra di origine che verrà utilizzato per replicare i dati. Può essere identificato utilizzando il seguente comando nel cluster di origine:
    kubectl get apigeedatastore -n ${APIGEE_NAMESPACE} -o=jsonpath='{.items[*].spec.components.cassandra.properties.datacenter}'

  • components/multi-region/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'IP di qualsiasi pod Cassandra, utilizza 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. Per garantire una comunicazione corretta tra i pod Cassandra, sia il cluster nuovo sia quello esistente devono utilizzare gli stessi certificati TLS. Pertanto, dovremo copiare il secret apigee-root-certificate dal cluster esistente e utilizzarlo anche in quello più recente:

  2. Esegui:

    kubectl config get-contexts
    • Per ottenere un elenco di tutti i contesti Kubernetes ed eseguire
    kubectl config use-context SOURCE_CLUSTER_CONTEXT

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

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

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

  4. Passa al contesto del 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. Disattiva la creazione di un nuovo certificato radice. In questo modo, non creeremo un nuovo apigee-root-certificate e non sovrascriveremo quello 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, dopo l'installazione di base di Apigee Hybrid, puoi eseguire:

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

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

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

  10. Verifica i processi di ricompilazione dai log. Inoltre, verifica le dimensioni 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.

    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: Deployment 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

Hub delle immagini

Le immagini container Docker sono generalmente specificate nel formato:

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

o quelli che utilizzano un riepilogo simile a questo:

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

Apigee utilizza il concetto di "Image Hub", che nei formati precedenti si riferisce a ${REGISTRY_HOST_PATH}. Il valore predefinito dell'hub delle immagini è gcr.io/apigee-release/hybrid/.

Le immagini che utilizzano DIGEST devono essere impostate singolarmente in ogni sottocomponente.

Apigee crea il percorso dell'immagine finale combinando il valore di quanto segue:

  • "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 viene ottenuto 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 la versione 1.8 di Apigee Hybrid
  • IMAGE_NAME viene determinato implicitamente dal nome del contenitore in cui verrà utilizzata l'immagine. Ad esempio, per il container apigee-runtime, IMAGE_NAME sarà apigee-runtime.

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

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

Service account Google Cloud

I service account Google Cloud sono account utilizzati dalle applicazioni per effettuare chiamate autorizzate alle API di Google. È possibile scaricare le chiavi del account di servizio Google Cloud, che possono poi essere utilizzate per l'autenticazione. Apigee prevede che l'utente fornisca le chiavi del account di servizio creando secret. Di seguito sono riportati i nomi dei componenti e il nome predefinito del secret in cui cerca le chiavi del account di servizio:

Componente Sottocomponente Nome secret Kubernetes predefinito contenente la chiave del account di servizio
organizzazione
connectAgent apigee-connect-agent-gcp-sa-key-${ORG_NAME}
watcher 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
environment
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}
telemetry
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 Workload Identity), puoi farlo specificando il campo podServiceAccountName nei vari sottocomponenti.

Elenco dei componenti e dei rispettivi sottocomponenti in cui è possibile specificare il account di servizio Kubernetes insieme al nome predefinito del account di servizio Kubernetes quando abiliti la patch di identità del workload.

Componente Sottocomponente Nome predefinito (disponibile quando hai abilitato la patch di Workload Identity)
organizzazione
connectAgent apigee-connect-agent-svc-account-${ORG_NAME}
watcher apigee-watcher-svc-account-${ORG_NAME}
mart apigee-mart-svc-account-${ORG_NAME}
udca apigee-udca-svc-account-${ORG_NAME}
environment
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
telemetry
metricsApp apigee-metricsApp-svc-account
metricsProxy apigee-metricsProxy-svc-account
metricsAdapter apigee-metricsAdapter-svc-account
containerLogs apigee-container-logs-svc-account

Identità del workload

Le identità dei workload consentono ai pod (che utilizzano i service account Kubernetes) in esecuzione in GKE di autenticarsi direttamente con le API Google Cloud senza richiedere le chiavi del account di servizio Google Cloud.

Aggiungere 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 è semplice:

  1. Creare una nuova cartella all'interno della directory degli ambienti (o in base alla struttura delle cartelle)
  2. Copia il file apigee-environment.yaml da qualsiasi ambiente esistente nella nuova cartella.
  3. Se vuoi creare nuove chiavi di crittografia e un nuovo account di servizio per il nuovo ambiente, copia secrets.yaml nella nuova cartella e rinomina i secret in modo appropriato per distinguerli dagli altri ambienti esistenti (in genere, aggiungendo il nome dell'ambiente come suffisso).
  4. Apportare le modifiche appropriate a apigee-environment.yaml, ad esempio:
    • Modificare il nome dell'ambiente
    • Se verranno creati nuovi service account e chiavi di crittografia, questi dovranno essere referenziati correttamente nel file YAML.
  5. Applicazione dei yaml:
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 il datastore Apigee può essere eliminato forzatamente utilizzando i seguenti comandi, indipendentemente dallo stato attuale del cluster.

  1. Elimina apigeeds nello spazio dei nomi apigee:

    Kubectl delete -n apigee apigeeds default

    Se questo passaggio si blocca, puoi uscire utilizzando Ctrl + C.

  2. Modifica un nuovo apigeeds:

    Kubectl edit -n apigee apigeeds default

  3. Aggiungi/aggiorna il campo forceDelete nella specifica del datastore Apigee

    spec:
forceDelete: true

  4. Salva il file ed esci.

Ora attendi l'eliminazione del datastore. L'eliminazione di tutte le risorse Cassandra può richiedere alcuni minuti.

Comprendere lo script

Lo script apigee-hybrid-setup.sh esegue alcune convalide di base e aiuta ad automatizzare i passaggi che altrimenti dovresti eseguire se vuoi una personalizzazione più dettagliata, come descritto in Installazione personalizzata di Apigee Hybrid. Anche con l'installazione personalizzata, puoi comunque utilizzare parzialmente lo script per aiutarti con determinate attività.

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

  • --namespace Per impostazione predefinita, lo script installa tutti i componenti nello spazio dei nomi apigee. Puoi modificare questo comportamento specificando il nome dello spazio dei nomi utilizzando questo flag.
  • --org Utilizzato per fornire il nome dell'organizzazione Apigee. Se non specificato, il valore predefinito è il progetto Google Cloud attualmente selezionato in gcloud
  • --envgroup Utilizzato per fornire il nome del gruppo di ambienti all'interno della tua organizzazione. Se non specificato, viene eseguito un tentativo di query delle API del control plane per determinare il nome del gruppo di ambienti. Se vengono trovati più gruppi di ambienti, viene restituito un errore e lo script viene chiuso.
  • --env Utilizzato per fornire il nome dell'ambiente all'interno della tua organizzazione. Se non specificato, viene effettuato un tentativo di eseguire query sulle API del control plane per determinare il nome dell'ambiente. Se vengono trovati più ambienti o l'ambiente non fa parte del gruppo di ambienti, viene restituito un errore e lo script viene chiuso.
  • --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 viene specificato alcun valore, viene eseguito un tentativo di determinare il valore eseguendo query sulle API del control plane per ottenere il valore da envgroup. Se si sono verificati problemi con la determinazione di envgroup o se sono stati configurati più nomi host per envgroup, viene restituito un errore e lo script viene chiuso.
  • --generate-internal-tls-certs Verrà creato un secret di Kubernetes denominato apigee-ca che contiene una coppia di certificato e chiave generata da noi.
  • --create-ingress-tls-certs Verrà generato un secret denominato {ORG_NAME}-{ENV_GROUP_NAME} (derivato dal nome dell'organizzazione e del gruppo di ambienti) all'interno dello spazio dei nomi istio-system che conterrà una coppia di certificato e chiave da utilizzare per la comunicazione TLS. Il nome di dominio utilizzato per generare questi certificati deriva dal valore trovato nella configurazione di envgroup. In caso di conflitti (ad esempio quando troviamo più domini), verranno visualizzati i messaggi di errore appropriati.
  • --create-gcp-sa-and-secrets Crea un singolo account di servizio Google Cloud nel progetto Google Cloud, scarica le chiavi e poi crea i secret Kubernetes contenenti la chiave. I nomi dei secret sono disponibili in Service account Google Cloud.
  • --fill-values Sostituisce i valori di org, env, envgroup e altri nomi ovunque siano richiesti nei vari file YAML.
  • --apply-configuration Verranno creati 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 verrà bloccato finché tutte non saranno integre.
  • -- rename-directories Rinomina l'ambiente e il gruppo di ambienti con i nomi dell'ambiente e del gruppo di ambienti corretti.
  • --verbose Mostra l'output dettagliato per il debug.
  • --help Visualizza le informazioni sull'utilizzo.
  • --setup-all Verranno eseguite tutte le attività che possono essere eseguite da questo script

Struttura delle cartelle di configurazione di Apigee Hybrid

Per impostazione predefinita, la cartella apigee-hybrid-setup ha la seguente struttura gerarchica:

.
├── 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 precedenti è disponibile nel tag preview-1 del repository GitHub all'indirizzo https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1.

La cartella precedente contiene i manifest Kubernetes per il runtime di Apigee Hybrid e utilizza Kustomize per la gestione della configurazione. I manifest sono organizzati in base al concetto di basi e overlay di Kustomize. La cartella bases contiene la configurazione minima richiesta per ogni componente Apigee. La cartella degli overlay contiene più funzionalità(configurazioni) aggiuntive definite come componenti. Un componente può essere decommentando il riferimento al componente nel file kustomization.yaml

Esempio :per abilitare gcs-backup per l'archivio dati Apigee, il componente gcs-backup è stato decommentato nel file customization.yaml riportato di seguito.

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 richiede personalizzazioni deve essere impostato nel file patch.yaml corrispondente per gcs-backup. Nel file riportato di seguito, 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 richiede personalizzazioni può essere abilitata rimuovendo il commento dal componente in 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.

overlay

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

inizializzazione

namespaces.yaml

Lo spazio dei nomi in cui verranno installati i componenti del data plane 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 anche Issuer utilizzato per emettere certificati per vari pod per la comunicazione TLS.

rbac

Contiene 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 eMutatingWebhookConfiguration che verranno utilizzati per eseguire le convalide sulle risorse personalizzate.

In entrata

Contiene la configurazione applicabile a tutti i pod Ingress. Es. Modifica dell'intestazione comune, controllo di integrità e così via.

openshift

Contiene la definizione di SecurityContextConstraints di OpenShift.

Controller

apigee-controller
apigee-hybrid-config.yaml

Contiene un ConfigMap fornito come input in apigee-controller-manager.yaml. Questo oggetto ConfigMap contiene configurazioni come imageHub, imagePullSecrets, forwardProxy, tra le altre.

apigee-controller-deployment.yaml

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

istiod

Apigee-istio-mesh-config.yaml Contiene la configurazione del mesh per Istio utilizzata da Apigee. Ciò non è applicabile ad altre installazioni di ASM/Istio nel cluster.

apigee-ingressgateway-manager-deployment-patch.yaml

Contiene un servizio e un deployment di Istiod. Si tratta di un istiod privato utilizzato solo per i casi d'uso di Apigee.

instances/{instanceName}

datastore
apigee-datastore.yaml

Contiene la risorsa personalizzata ApigeeDatastore che gestisce Cassandra.

secrets.yaml

Contiene le credenziali predefinite per il datastore.

redis
apigee-redis.yaml

Contiene la risorsa personalizzata ApigeeRedis che gestisce Redis.

secrets.yaml

Contiene le credenziali predefinite per il datastore.

organizzazione
apigee-organization.yaml

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

secrets.yaml

Contiene i Secrets a cui viene fatto riferimento in apigee-organization.yaml. Alcuni segreti sono commentati perché vengono generati dallo script. Se disattivi la generazione, dovrai creare manualmente

environments

Contiene tutti gli ambienti della tua organizzazione. Devi creare una cartella separata per ogni ambiente copiando quella già fornita e configurandola in base ai requisiti.

dev
apigee-environment.yaml

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

secrets.yaml

Contiene i Secrets a cui viene fatto riferimento in apigee-environment.yaml. Alcuni segreti sono commentati perché vengono generati dallo script. Se disattivi la loro generazione, dovrai crearli manualmente

telemetria
apigee-telemetry.yaml

Contiene la risorsa personalizzata ApigeeTelemetry.

secrets.yaml

Contiene i Secret a cui viene fatto riferimento in apigee-telemetry.yaml. Alcuni segreti sono commentati perché vengono generati dallo script. Se disattivi la generazione, dovrai creare manualmente

route-config
dev-envgroup
apigee-route-config.yaml

Contiene la risorsa personalizzata ApigeeRouteConfig.

secrets.yaml

Contiene un Secret a cui viene fatto riferimento in apigee-route-config.yaml. È commentato perché viene generato automaticamente dallo script apigee-hybrid-setup.sh e viene mantenuto lì per fornire un esempio di come dovrebbe apparire il secret se lo creassi manualmente.

diagnostico

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 del account di servizio in vault esterni

Vault (di Hashicorp) è un sistema di gestione dei secret molto diffuso che presenta diverse integrazioni con gli archivi dei secret forniti da Google, Azure, AWS e altri. Hashicorp Vault consente di recuperare i secret da una fonte esterna e utilizzarli all'interno delle risorse Kubernetes. Esistono diversi modi per utilizzare Vault per recuperare i secret. I seguenti passaggi fungono da esempio di base su come utilizzare il provider CSI Vault per montare le chiavi del account di servizio Google Cloud archiviate in un motore di secret fornito da 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 Installare 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 dei secret chiave/valore per archiviare i dati.

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

    3. Per verificare che la chiave sia stata archiviata correttamente, utilizza:

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

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

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

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

    2. Abilita il metodo di autenticazione 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. Crea il criterio di autenticazione

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

    5. Associa la policy al 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, supponiamo che l'account di servizio si trovi nello spazio dei nomi apigee. Se hai un altro spazio dei nomi per l'installazione di Apigee, utilizzerai questo nome.

    1. Esci dalla shell all'interno di vault-0

      exit

  5. Installa il driver CSI Secrets Store

    # 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 una risorsa Kubernetes SecretProviderClass che fa riferimento al secret che hai creato all'interno del 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. Applica yaml

    kubectl apply -f spc-vault.yaml

  8. Crea il 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

Upgrade di Apigee hybrid

Devi aver completato tutti i requisiti menzionati in Prerequisiti. Inoltre, ti consigliamo di eseguire un riavvio sequenziale di tutti i componenti per verificare l'integrità del cluster. L'ordine di riavvio sarà Cassandra, Redis, ApigeeOrganization e ApigeeEnvironment.

Crea backup

  1. Crea una copia di backup della configurazione ibrida attuale. Il backup sarà necessario nel caso in cui tu debba eseguire il rollback dell'upgrade alla versione attuale.

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

  2. Crea il backup del database Cassandra. I backup di Cassandra sono un'importante misura di protezione contro scenari di emergenza.

Esegui l'upgrade della piattaforma Kubernetes, se necessario

Questo passaggio non è obbligatorio ogni volta, ma dovrai eseguire l'upgrade della piattaforma Kubernetes come Kubernetes, Openshift e dei componenti come cert-manager, Cassandra e così via se non sono più supportati dalla versione più recente di Apigee Hybrid. La documentazione conterrà le versioni supportate di piattaforme e componenti.

Scaricare i file di configurazione

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 all'indirizzo https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1

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

  2. sostituisci l'inizializzazione, gli strumenti e la cartella del controller nella configurazione ibrida 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 del account di servizio, se necessario

Anche questo passaggio non è obbligatorio ogni volta, ma dovrai creare un nuovo account di servizio o aggiornare le autorizzazioni dei service account esistenti, se necessario. La guida all'upgrade fornisce i dettagli sui service account da modificare o creare e sui ruoli da aggiungere.

  • Se devi modificare le autorizzazioni dei service account esistenti, utilizza il comando gcloud appropriato. La guida all'upgrade conterrà i comandi e i ruoli dettagliati da aggiungere.

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

  • Se la versione più recente di Apigee Hybrid potrebbe richiedere un account di servizio aggiuntivo per i componenti nuovi / esistenti, devi crearli. Puoi utilizzare lo script apigee-create-service-account.sh fornito nella cartella degli strumenti per creare nuovi service account. Poiché lo script verrà già aggiornato nell'ambito del passaggio 4, conterrà i dettagli e un nuovo profilo necessari per un nuovo account di servizio da creare.

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

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

Esegui l'upgrade del controller

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 della 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 fornita in Crea risorse di inizializzazione e controller nel flusso di lavoro di installazione di Apigee hybrid. Puoi utilizzare lo script o seguire i passaggi manuali forniti per eseguire l'upgrade delle risorse di inizializzazione e del controller.

Aggiorna i componenti Kubernetes di Apigee

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, devi aggiornare i campi della 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 di Apigee. Per l'ambiente non di produzione, puoi applicare tutte le modifiche ai componenti Apigee contemporaneamente

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

Rollback di Apigee Hybrid

  1. Ripristina apigee-hybrid-setup

    Spostati nella directory che contiene la versione precedente della configurazione di Apigee hybrid. Se non è disponibile, ripristinalo dal file zip creato nel passaggio 1 [link] durante l'upgrade di Apigee Hybrid.

  2. Eseguire il rollback dei componenti di Kubernetes

    Applica le modifiche per i CR apigee

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

  3. Controller di rollback

    Segui la stessa serie di passaggi forniti per creare risorse di inizializzazione e controller nel flusso di lavoro di installazione di Apigee hybrid. Puoi utilizzare uno script o seguire i passaggi manuali forniti per eseguire il rollback delle risorse di inizializzazione e del controller.

  4. Esegui la pulizia

    Dovrai eseguire la pulizia di eventuali nuove risorse aggiuntive create durante l'upgrade, come nuovi componenti o service account introdotti nella versione più recente di ibrido. Nella guida all'upgrade verranno fornite tutte le risorse da pulire e i passaggi per farlo.

Eliminazione di un ambiente

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

  1. Recupera il nome della CR dell'ambiente. Per farlo, recupera 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. Elimina i service account 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

Di seguito sono riportati i passaggi per eliminare tutte le risorse correlate 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. Dovrai eliminare i componenti del piano dati ibrido di Apigee di cui è stato eseguito il deployment. Utilizza questo 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 secret account di servizio Kubernetes, i secret account di servizio Google Cloud e così via. 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, devi eliminare scc (Security Context Constraints) creato 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, utilizza 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 delle stesse regioni. Apigee consiglia di organizzare le configurazioni della seconda istanza in una struttura di directory separata,poiché le configurazioni dell'ambiente (repliche e così via) 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 Active-Passive in uno scenario multiregionale, potresti voler configurare una seconda regione in warm standby con dimensioni e configurazioni diverse.

Nella struttura delle cartelle riportata di seguito, puoi creare una copia della directory instance1 denominata instance2 e modificare le configurazioni di datastore e ingresso in base alle esigenze.

Struttura delle cartelle apigee-hybrid-setup per la configurazione di più istanze.

.
├── 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 di più istanze su GKE

Prerequisiti

Prima di configurare più istanze di ibrido, devi aver completato i seguenti prerequisiti:

  • Configura cluster Kubernetes in più regioni(uguali o diverse) con blocchi CIDR diversi
  • 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.

Puoi 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 dello spazio dei nomi se è diverso dallo spazio dei nomi instance1.
  3. Segui i passaggi specificati in Specifica dei certificati TLS in entrata per modificare la configurazione in entrata per l'altra istanza.

  4. Per informazioni sulla configurazione dell'IP del bilanciatore del carico per l'altra istanza, consulta Gestione del gateway in entrata Apigee.

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

    kubectl config use-context original-cluster-name

  6. Esegui 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. Qualsiasi IP del pod restituito dal comando precedente può essere considerato l'host seed multiregionale.

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

Configurare la nuova istanza

  1. Imposta il contesto sul cluster esistente

    kubectl config use-context existing-cluster-name

  2. Esporta il secret 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 secret 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. Recupera 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. Puoi scegliere un nome come "cassandra-data-replication".
    • NAMESPACE è lo stesso spazio dei nomi scelto per la seconda istanza. che in genere è "apigee".
    • APIGEEORG_VALUE è il valore restituito dal comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" nel passaggio precedente.
    • SOURCE_REGION è il valore del valore del datacenter Cassandra dallo stato di nodetool del cluster di origine.

  8. Applica CassandraDataReplication con il seguente comando:

    kubectl apply -f datareplication.yaml

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

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

    Il risultato dovrebbe essere simile a questo:

    {
"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 le dimensioni dei dati utilizzando il comando nodetool status:

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

    Fai riferimento a datastore/secrets.yaml per JMX_user e JMX_password

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

  11. Rimuovi multiRegionSeedHost dal CR del datastore Apigee ed esegui il comando riportato di seguito 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 è riuscita 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 risoluzione dei problemi, alla diagnostica e all'assistenza

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

Pulizia manuale dopo l'utilizzo di forceDelete nella configurazione di Apigee Hybrid multiregionale

  • Nel seguente esempio, ci sono due regioni: us-east1 e us-west1.
  • Nella regione us-west1, l'archivio dati Apigee è stato eliminato utilizzando l'eliminazione forzata.
  • Nella regione us-east1, Cassandra è ancora in esecuzione.

  • Verifica che apigeeds sia stato eliminato utilizzando il comando

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

  • Cambia il contesto kubectl con l'altra regione in cui il cluster Cassandra è ancora in esecuzione (in questo caso us-east1).

  • Verifica che il datastore sia in esecuzione

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

  • Esegui l'accesso a uno dei pod Cassandra nella regione di cui è stato eseguito il provisioning (in questo caso us-east1)

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

  • Controlla lo stato di nodetool, che mostrerà tutti i nodi inattivi nella regione eliminata (in questo caso 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

  • Verifica che non siano rimasti nodi della regione eliminata (in questo caso 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, elimina il job di configurazione utente nella regione up (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 del job 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

  • Verifica 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 es. per la versione ibrida 1.5 - link, ibrida 1.6 - link) e poi esegui l'accesso al 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:

  • Verifica che la regione us-west1 sia 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)