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

Guida dell'utente di anteprima:
Anteprima delle nuove procedure di installazione e amministrazione per Apigee hybrid 1.8.

In questo documento:

Anteprima

Questo documento è rivolto all'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 di Apigee utilizzando kubectl e integra l'installazione e la gestione di Apigee Hybrid con gli strumenti di orchestrazione della configurazione di Kubernetes come Kustomize. Le verifiche e la visibilità migliorate dei componenti in fase di installazione offrono una migliore possibilità di debug e migliorano la procedura di installazione complessiva.

Uno script di installazione, apigee-hybrid-setup.sh, fornisce uno strumento facile 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 memorizzate in file yaml, uno per ogni componente principale. In questo modo, puoi avere un controllo molto più granulare dell'installazione ibrida nel tuo 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 creazione di modelli personalizzati che genera manifest Kubernetes (tra le altre cose) per installare e gestire Apigee hybrid nei cluster Kubernetes. La nuova procedura di installazione e gestione offre un'esperienza simile a quella di altri fornitori di software.
  • La nuova procedura consente di eseguire rapidamente l'installazione di base creando automaticamente account di servizio con le autorizzazioni richieste, certificati TLS, valori predefiniti precompilati e altri elementi di base necessari.

Prerequisiti

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

Versione di anteprima

Questa anteprima è progettata 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 istruzioni riportate nelle seguenti sezioni della documentazione:

  1. Configurazione di progetto e organizzazione
  2. Configurazione del runtime di hybrid

Strumenti

Inoltre, devi aver scaricato e configurato sulla tua workstation i seguenti strumenti:

  • curl
  • docker è necessario per eseguire lo script apigee-hybrid-setup.sh. Segui le istruzioni riportate in Ottenere 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 in questo repo.
  • jq deve essere installato. Scarica jq.

  • kpt Scarica kpt.

  • kubectl versione 1.23 o successive. Consulta 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 a riga di comando o con uno script oppure puoi sostituire il testo nei comandi quando li inserisci.

  • APIGEE_NAMESPACE: lo 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. Si tratta del cluster creato nel passaggio 1: crea un cluster
  • CLUSTER_LOCATION: la regione del cluster. Le procedure descritte in questa guida presuppongono che tu stia utilizzando un cluster a livello di regione. Se utilizzi un cluster di zona, consulta le istruzioni riportate nel passaggio 1: crea un cluster.
  • ENV_GROUP: il nome del gruppo di ambienti per l'installazione di Apigee hybrid. Si tratta del gruppo di ambienti creato 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. Si tratta del gruppo di ambienti creato 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 della struttura dei file descritta in Struttura della cartella di configurazione di Apigee hybrid.
  • INSTANCE_DIR: la directory di un'istanza Apigee hybrid specifica. Per impostazione predefinita, la prima istanza è denominata 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 con più istanze.
  • ORG_NAME: il nome della tua organizzazione Apigee hybrid. Deve essere uguale all'ID progetto Google Cloud. Consulta 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 singolo 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 e le password di crittografia.
  1. Scaricare i file di configurazione
  2. Eseguire la 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 ramo 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 della cartella di configurazione di Apigee Hybrid:

Esegui la configurazione

Esegui lo script shell apigee-hybrid-setup.sh all'interno della cartella tools/.

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

Se si verificano errori, prova a eseguire lo script una seconda volta.

Ecco alcune opzioni aggiuntive che puoi utilizzare:

  • --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 altre opzioni, consulta Informazioni sullo script.

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

Al termine dello script, avrai completato l'installazione ibrida di base. Puoi testare l'installazione creando un proxy di esempio come descritto in Creare e implementare un nuovo proxy API.

Installazione di Apigee Hybrid personalizzata

Gli utenti più esperti che vogliono un controllo granulare sull'installazione possono seguire questa sequenza di passaggi (per molti dei passaggi indicati di seguito, puoi scegliere di eseguirlo manualmente o di 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 della cartella 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 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 precompletamento dei valori in Modifica i file yaml delle risorse.

  • Esegui i due comandi che seguono:

    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 discoveryAddress di Istio:

      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 da creare singolarmente 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 quelle dei tuoi repository privati:

  1. Il primo passaggio consiste nell'eseguire il push di tutte le immagini nel tuo repository privato, seguendo i passaggi descritti in apigee-pull-push | Apigee X. Per impostazione predefinita, le immagini sono contrassegnate con la versione di Apigee Hybrid a cui corrispondono e ti consigliamo di non modificarle. Ti consigliamo inoltre di non modificare i nomi delle immagini in modo che il percorso dell'immagine finale possa essere costruito come spiegato in Image Hub.

  2. Imposta il valore del campo imageHub presente all'interno del file apigee-hybrid-config.yaml sul percorso dell'host del repository privato. (per maggiori dettagli, visita la pagina Image Hub).

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

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

Inoltre, ti consigliamo di utilizzare un'immagine privata per il controller e per il gateway di ingresso Apigee, per il quale 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 Estrarre un'immagine da un registry privato per capire come deve essere creato il secret.
  2. Una volta creato il segreto, non resta che fare riferimento al segreto, modificando il file apigee-hybrid-config.yaml e impostando il valore del campo imagePullSecret sul nome del segreto creato in precedenza, nonché attivando il componente imagePullSecret nel file kustomization.yaml corrispondente.

Se specifichi imagePullSecrets in entrambi i casi, avrà la precedenza quello presente all'interno del file apigee-controller-manager.yaml.

(Facoltativo) Configurazione del proxy inoltrante

I proxy inoltra 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

Specifica dei certificati TLS di ingresso

Utilizzare lo script

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

Per ulteriori dettagli su questo flag, consulta Informazioni sullo script.

Manuale

Dovresti fornire i certificati TLS che verranno utilizzati per il gateway di ingresso Istio. Puoi:

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

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 segreto nel seguente formato. Puoi utilizzare kubectl create o kubectl apply come spiegato in Utilizzo di una coppia di chiavi/certificati personalizzati per l'autorità di certificazione (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 di 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, viene creato un deployment di ingress con parametri predefiniti(i valori predefiniti verranno mostrati nella documentazione di riferimento del CR ):

ingressGateways:
- name: "prod-1"

Esempi:

A. Sostituzione dei campi del servizio in entrata

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

B. Modifica numero minimo/massimo di repliche

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

C. Aggiunta di un nuovo deployment di Ingress

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

Configurazione di account di servizio Google Cloud personalizzati

Utilizzare lo script

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

Dove APIGEE_NAMESPACE è lo spazio dei nomi personalizzato. Lo spazio dei nomi predefinito è apigee.

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

Manuale

Le chiavi degli account di servizio Google Cloud devono essere archiviate come secret nel cluster. Il file yaml del segreto 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 gli account di servizio richiesti e sui nomi dei secret, consulta la sezione Account di servizio 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 cambiare il nome del segreto dell'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.

Utilizzare le identità per i carichi di lavoro

È obbligatorio scegliere una delle opzioni Configurare account di servizio Google Cloud personalizzati o Utilizzare le identità del carico di lavoro.

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.

Attivazione di workload-identity

Consulta la sezione Identità di carico di lavoro in Kustomize e componenti per informazioni dettagliate su come abilitare le identità di carico di lavoro prima dell'installazione.

Modifica i file yaml delle risorse

Alcuni punti nei 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 all'account di servizio Synchronizer per interagire con il Control Plane

Segui i passaggi descritti in Passaggio 8: attivazione dell'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 dell'account di servizio nelle istruzioni riportate in Attivare l'accesso del sincronizzatore. In caso contrario, l'attivazione dell'accesso per il sincronizzatore non andrà a buon fine.

Crea 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 è stato fatto riferimento alla risorsa. Al termine, utilizza i comandi nel seguente esempio:

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

per installare tutti i componenti.

Attendi l'avvio delle risorse

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

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

Personalizza lo spazio dei nomi in cui è in esecuzione cert-manager con la procedura seguente.

Se cert-manager è installato nel cluster in un altro spazio dei nomi diverso da cert-manager, dovrai aggiornare lo spazio dei nomi utilizzato per creare il certificato principale 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 tra 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 dell'utente e consentono di modificare i valori predefiniti specificati nelle basi. Tutti i file nella cartella overlays/ di primo livello contengono questi overlay

Come utilizzare Componenti

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

Ad esempio, la struttura della cartella overlays/instances/{INSTANCE_NAME}/telemetry è la seguente:

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

Ecco come potrebbero essere i file telemetry/kustomization.yaml per impostazione predefinita:

resources:
- apigee-telemetry.yaml

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

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

components:

- ./components/logger

Analogamente, per disattivare le metriche, puoi commentare la riga ./components/metrics:

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

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

OpenShift

Gli utenti che vogliono installare Apigee Hybrid in un cluster OpenShift potrebbero dover attivare alcuni componenti/risorse prima di eseguire l'installazione. (questo passaggio è obbligatorio se non utilizzi lo script per eseguire l'installazione). I file che devono essere modificati 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 rimuovere il commento dal campo "components:" se è ancora commentato.

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

    # - ./components/openshift-scc

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

A questo punto puoi procedere con i passaggi di installazione.

imagepullsecret

Questo componente può essere attivato se hai immagini archiviate nel tuo repository privato. Per estrarre le immagini da un repository privato, puoi creare un secret Kubernetes che contenga i tuoi dati di autenticazione e poi fare riferimento a questo secret all'interno. Per le istruzioni, consulta Configurare imagePullSecrets (facoltativo). Per ulteriori informazioni, consulta Eseguire il pull di un'immagine da un registry privato | 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:

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

Modifiche da apportare:

  • components/imagepullsecret/patch.yaml
    • OBBLIGATORIO Aggiungi i nomi delle chiavi segrete 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 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:

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

Modifiche da apportare:

  • components/nodeselector/patch.yaml
    • FACOLTATIVO Modifica il valore dell'etichetta del selettore 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

Vari contenitori nell'ecosistema Apigee Hybrid richiedono autorizzazioni per effettuare determinate chiamate API al Control Plane / Management Plane di Apigee. L'identità del carico di lavoro è uno dei modi per concedere queste autorizzazioni ai pod (e ai container al loro interno). Di seguito sono riportate alcune risorse utili per saperne di più: - Introduzione a Workload Identity: autenticazione migliorata per le applicazioni GKE | Blog Google Cloud - Utilizzare Workload Identity | Documentazione di Kubernetes Engine | Google Cloud

Disponibile in:

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

Prerequisito:

Prima di poter utilizzare l'identità del carico di lavoro, devi concedere le autorizzazioni pertinenti nel 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 venga modificato esplicitamente dall'utente durante l'installazione. - ${KSA_NAME}: il nome dello spazio dei nomi Kubernetes. Dovrai eseguire questo comando per ogni account di servizio Kubernetes menzionato in Account di servizio Kubernetes - ${GSA_NAME}: il nome dell'account di servizio Google Cloud. Se non hai apportato modifiche durante l'installazione, il valore sarà apigee-all-sa. Se configuri più account di servizio Google Cloud per i singoli componenti, devi associare KSA_NAME al GSA_NAME corrispondente. Puoi confrontare le tabelle degli account di servizio Google Cloud con gli account di servizio Kubernetes per trovare gli equivalenti.

Attivazione:

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

Utilizzo:

  1. Se non hai ancora installato la versione ibrida, puoi semplicemente attivare Workload Identity come indicato nella sezione precedente e continuare con l'installazione, che utilizzerà automaticamente Workload Identity.

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

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

http-proxy

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

Disponibile in:

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

Attivazione:

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

Modifiche da apportare:

  • components/http-proxy/patch.yaml I seguenti parametri possono essere configurati in spec.httpForwardProxy
    • scheme: OBBLIGATORIO Uno di 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 in overlays/instances/{INSTANCE_NAME}/telemetry. Per impostazione predefinita, il logger è disattivato e le metriche sono attivate. Per attivarli o disattivarli, è sufficiente rimuovere o aggiungere i commenti alle relative righe in telemetry/kustomization.yaml

gcs-backup e gcs-restore

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

Disponibile in:

  • overlays/instances/{INSTANCE_NAME}/datastore

Prerequisito:

  1. Scarica le chiavi degli account di servizio 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 degli account di servizio creata dallo script.

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

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

  2. Una volta scaricate le chiavi, devi creare un segreto Kubernetes con il nome apigee-cassandra-backup-and-restore-gcp-sa-key, utilizzando il seguente 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 si tratta di 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 segreto.

Attivazione:

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

Modifiche solo per il backup

  • components/gcs-backup/apigee-datastore-patch.yaml
    • OBBLIGATORIO Modifica il valore della variabile di ambiente DATABASE_STORAGE_BUCKET, che avrà il formato gs://BUCKET_NAME e punta al bucket Google Cloud Storage in cui è necessario eseguire il 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 della pianificazione di Crontab standard. 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 punta al bucket Google Cloud Storage in cui è necessario eseguire il backup dei dati. La descrizione corrisponde a dbStorageBucket descritto qui.
    • FACOLTATIVO Modifica il valore di HTTP_PROXY_URL in modo che rimandi 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}

Eseguire il 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 sarà del tipo gs://BUCKET_NAME e punta al bucket Google Cloud Storage in cui deve essere eseguito il 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 sarà del tipo gs://BUCKET_NAME e punta al bucket Google Cloud Storage in cui deve essere eseguito il backup dei dati.
    • OBBLIGATORIO Modifica il valore della variabile di ambiente BACKUP_SNAPSHOT_TIMESTAMP. La descrizione corrisponde a restore:snapshotTimestamp descritto qui.
    • FACOLTATIVO Modifica il valore di HTTP_PROXY_URL in modo che rimandi 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}

Esegui il ripristino:

Per informazioni di base sul ripristino dei backup, consulta 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 utilizzati per l'installazione ibrida originale.

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

    • 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. Al termine del ripristino, tutte le risorse nello spazio dei nomi precedente potrebbero essere eliminate e passare al nuovo spazio dei nomi.

Per ulteriori informazioni, consulta Ripristino dei backup.

non-gcs-backup e non-gcs-restore

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

Disponibile in:

  • overlays/instances/{INSTANCE_NAME}/datastore

Prerequisito:

  1. Puoi utilizzare i passaggi della documentazione già esistente per la configurazione del server e di SSH.

  2. Dai passaggi precedenti, dovrai utilizzare la chiave privata SSH disponibile nel file "ssh_key" generato seguendo i passaggi precedenti. Creeremo quindi un secret Kubernetes denominato apigee-cassandra-backup-and-restore-gcp-sa-key contenente 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 si tratta di apigee, a meno che non venga 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 segreto.

Attivazione:

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

Modifiche solo per il backup

  • components/non-gcs-backup/apigee-datastore-patch.yaml
    • OBBLIGATORIO 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 della pianificazione di Crontab standard. 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 rimandi 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}

Eseguire il 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 descritta qui.
    • OBBLIGATORIO Modifica il valore di BACKUP_STORAGE_DIR. La descrizione corrisponde a BACKUP_STORAGE_DIR descritta qui.
  • components/non-gcs-restore/job-patch.yaml
    • OBBLIGATORIO Modifica il valore della variabile di ambiente BACKUP_SNAPSHOT_TIMESTAMP. La descrizione corrisponde a restore:snapshotTimestamp descritta qui.
    • OBBLIGATORIO Modifica il valore di BACKUP_SERVER_IP. La descrizione corrisponde a BACKUP_SERVER_IP descritta qui.
    • OBBLIGATORIO Modifica il valore di BACKUP_STORAGE_DIR. La descrizione corrisponde a BACKUP_STORAGE_DIR descritta qui.
    • FACOLTATIVO Modifica il valore di HTTP_PROXY_URL in modo che rimandi 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}

Esegui il ripristino:

Per una panoramica del ripristino dei backup, consulta la 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 utilizzati per l'installazione ibrida originale.

  2. Installa Hybrid nel nuovo cluster con le impostazioni configurate sopra, oltre a qualsiasi altra impostazione che preferisci: 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 di Apigee Hybrid personalizzata per configurare le impostazioni in base alla tua scelta.

  3. Al termine del ripristino, tutte le risorse nello spazio dei nomi precedente potrebbero essere eliminate e passare al nuovo spazio dei nomi.

    Per ulteriori informazioni, consulta Pianificare i backup su un server remoto.

http-client

Per le istruzioni, vedi Attivare i client HTTP | Apigee.

Disponibile in:

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

Attivazione:

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

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 della pagina Come configurare un client non SNI | Apigee già esistente.

Disponibile in:

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

Attivazione:

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

Modifiche da apportare:

  • components/non-sni-client/apigee-route.yaml
    • OBBLIGATORIO La descrizione credentialName corrisponde a 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 Attivare il supporto sia per i client non SNI sia per i client HTTP | Apigee.

Attivazione:

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

Modifiche da apportare:

  • components/http-and-non-sni-client/apigee-route.yaml
    • OBBLIGATORIO La descrizione credentialName corrisponde a 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}

multiregionale

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

Attivazione:

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

Modifiche da apportare:

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

    • OBBLIGATORIO source.region Il nome del data center Cassandra di origine da cui verranno replicati 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 del pod di uno 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 ulteriori informazioni, consulta i 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 di Apigee Hybrid funzionante.

  1. Sia il cluster nuovo che quello esistente devono utilizzare gli stessi certificati TLS per garantire una comunicazione corretta tra i pod Cassandra. 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 eseguirli
    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 il contesto del cluster al nuovo cluster in cui stai installando Apigee Hybrid.

    kubectl config use-context ${NEW_CLUSTER_CONTEXT}

  5. Crea il secret principale nel nuovo cluster:

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

  6. Disattiva la creazione di un nuovo certificato radice. In questo modo, eviteremo di creare un nuovo apigee-root-certificate e di sovrascrivere 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 Apigee Hybrid di base o l'installazione di Apigee Hybrid personalizzata. Ad esempio, dopo aver seguito la procedura di 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 ricostruzione utilizzando il seguente comando.

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

  10. Verifica le procedure di ricostruzione dai log. Verifica anche 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 ricostruzione utilizzando il seguente comando.

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

    I risultati dovrebbero avere il seguente aspetto:

    {
"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. Rimuovi le 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

Image Hub

Le immagini container Docker sono generalmente specificate nel formato:

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

o che utilizzano un riepilogo simile al seguente:

${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 di immagini è gcr.io/apigee-release/hybrid/.

(le immagini che utilizzano DIGEST devono essere impostate singolarmente in ogni sottocomponente)

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

  • "Image Hub", che può essere sostituito in apigee-hybrid-config.yaml (fai riferimento alla sezione Utilizzare immagini Docker da repository privati per la procedura dettagliata su come eseguire l'override di Image Hub).
  • Il valore di IMAGE_TAG viene ottenuto dal campo version, presente all'interno del file yaml per ogni singolo componente (ad esempio apigee-organization.yaml). Apigee contrassegna le immagini con la versione di Apigee Hybrid, ovvero 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 contenitore apigee-runtime, IMAGE_NAME sarà apigee-runtime.

Pertanto, un esempio completo di percorso immagine è 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 contenitore nei rispettivi pod.

Account di servizio Google Cloud

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

Componente Sottocomponente Nome del secret Kubernetes predefinito contenente la chiave dell'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}
telemetria
metriche apigee-metrics-gcp-sa-key
containerLogs apigee-logger-gcp-sa-key

Account di servizio Kubernetes

Gli account di servizio Kubernetes forniscono identità ai pod nel cluster. Per impostazione predefinita, Apigee Controller li crea per te. Tuttavia, se vuoi eseguire l'override della creazione (ad esempio quando utilizzi le identità di carico di lavoro), puoi farlo specificando il campo podServiceAccountName nei vari componenti secondari.

Elenco dei componenti e dei rispettivi componenti secondari in cui è possibile specificare l'account di servizio Kubernetes insieme al nome predefinito dell'account di servizio k8s quando attivi la patch per l'identità del carico di lavoro.

Componente Sottocomponente Nome predefinito (disponibile se hai attivato 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
telemetria
metricsApp apigee-metricsApp-svc-account
metricsProxy apigee-metricsProxy-svc-account
metricsAdapter apigee-metricsAdapter-svc-account
containerLogs apigee-container-logs-svc-account

Workload Identity

Le identità del carico di lavoro consentono ai pod (che utilizzano account di servizio Kubernetes) in esecuzione in GKE di autenticarsi direttamente con le API Google Cloud senza richiedere le chiavi dell'account di servizio Google Cloud.

Aggiunta di un nuovo ambiente

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

Per aggiungere un nuovo ambiente, basta:

  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 alla nuova cartella.
  3. Se vuoi creare nuovi account di servizio e chiavi di crittografia per il nuovo ambiente, copia secrets.yaml nella nuova cartella e rinomina i secret in modo appropriato per distinguerli dagli altri ambienti esistenti (di solito questo viene fatto aggiungendo il nome dell'ambiente come suffisso).
  4. Apportare le modifiche appropriate al apigee-environment.yaml, ad esempio:
    • Modificare il nome dell'ambiente
    • Se devono essere creati nuovi account di servizio e nuove chiavi di crittografia, è necessario fare riferimento a questi elementi 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 corrente del cluster.

  1. Elimina apigeeds nello spazio dei nomi apigee:

    Kubectl delete -n apigee apigeeds default

    Se questo passaggio si blocca, puoi uscirne utilizzando CTRL + C.

  2. Modificare un nuovo apigeeds:

    Kubectl edit -n apigee apigeeds default

  3. Aggiungere/aggiornare il campo forceDelete nella specifica del datastore Apigee

    spec:
forceDelete: true

  4. Salva il file ed esci.

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

Informazioni sullo 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 di Apigee Hybrid personalizzata. 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 di flag supportati e ricevere ulteriore assistenza 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 tentato di eseguire una query sulle API del piano di controllo per determinare il nome del gruppo di ambienti. Se vengono trovati più gruppi di ambienti, viene restituito un errore e lo script esce.
  • --env Utilizzato per fornire il nome dell'ambiente all'interno della tua organizzazione. Se non specificato, viene tentato di eseguire una query sulle API del piano di controllo per determinare il nome dell'ambiente. Se vengono trovati più ambienti o se l'ambiente non fa parte del gruppo di ambienti, viene restituito un errore e lo script esce.
  • --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 tentato di determinarlo eseguendo una query sulle API del piano di controllo per ottenere il valore dall'envgroup. Se si sono verificati problemi con la determinazione dell'envgroup o sono stati configurati più nomi host per l'envgroup, viene restituito un errore e lo script esce.
  • --generate-internal-tls-certs Verrà generato un secret Kubernetes denominato apigee-ca contenente un certificato e una coppia di chiavi generati 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à un certificato e una coppia di chiavi da utilizzare per la comunicazione TLS. Il nome di dominio utilizzato per generare questi certificati è dedotto dal valore trovato nella configurazione del gruppo di ambienti. In caso di conflitti (ad esempio quando vengono trovati più domini), verranno visualizzati 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 negli account di servizio 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 dei certificati, le definizioni di risorse personalizzate, gli webhook, i ruoli e la risorsa del controller. Le risorse verranno create nell'ordine corretto e il comando verrà bloccato finché non saranno tutte attive.
  • -- 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 Mostra le informazioni sull'utilizzo.
  • --setup-all Verranno eseguite tutte le attività che possono essere eseguite da questo script

Struttura della cartella 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 sopra indicata 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 delle basi 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 rimuovendo il commento dal riferimento al componente in kustomization.yaml

Esempio : per attivare gcs-backup per il datastore apigee, il componente gcs-backup non è stato commentato 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 dovrà 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"

Analogamente, qualsiasi funzionalità/configurazione che richiede personalizzazioni può essere attivata rimuovendo il commento dal componente nel file kustomization.yaml del componente apigee. Inoltre, come richiesto, 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 di apigee. Non è necessario apportare modifiche ai manifest in questa cartella.

overlay

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

inizializzazione

namespaces.yaml

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

certificati

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

rbac

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

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

Contiene ValidatingWebhookConfiguration e MutatingWebhookConfiguration che verranno utilizzati per eseguire 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 ConfigMap contiene configurazioni come imageHub, imagePullSecrets, forwardProxy e altre ancora.

apigee-controller-deployment.yaml

Contiene due servizi per il controller e l'webhook, nonché il deployment per il controller. Se vuoi utilizzare un'immagine privata per il controller, devi apportare la modifica qui.

istiod

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

apigee-ingressgateway-manager-deployment-patch.yaml

Contiene un servizio e il 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 componenti secondari come connectAgent, watcherAndSynchronizer, MART,UDCA e Ingress.

secrets.yaml

Contiene i Secret a cui viene fatto riferimento in apigee-organization.yaml. Alcuni secret vengono ignorati perché generati dallo script. Se disattivi la loro generazione, dovrai crearli manualmente

environments

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

dev
apigee-environment.yaml

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

secrets.yaml

Contiene i Secret a cui viene fatto riferimento in apigee-environment.yaml. Alcuni secret vengono ignorati perché 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 si fa riferimento in apigee-telemetry.yaml. Alcuni secret vengono ignorati perché generati dallo script. Se disattivi la loro generazione, dovrai crearli 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 essere il segreto se lo crei manualmente.

diagnostica

diagnostic-collector.yaml

Risorse che verranno utilizzate per avviare il deployment diagnostico

strumenti

apigee-hybrid-setup.sh
apigee-create-service-account.sh
dump-kubernetes.sh
apigee-pull-push.sh

Memorizzazione delle chiavi dell'account di servizio in cassette di sicurezza esterne

Vault (di Hashicorp) è un popolare sistema di gestione dei secret che offre diverse integrazioni con gli store di secret forniti da Google, Azure, AWS e altri. Hashicorp Vault ti consente di recuperare i secret da un'origine esterna e di utilizzarli nelle risorse Kubernetes. Esistono diversi modi per utilizzare Vault per recuperare i secret. I passaggi che seguono sono un esempio di base su come utilizzare il provider CSI di Vault per montare le chiavi dell'account di servizio Google Cloud archiviate in un'engine segreto fornita da Vault.

  1. Utilizzeremo Helm per installare le risorse correlate a Vault nel cluster. Segui i passaggi descritti in Installare Helm per configurare Helm nel 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 memorizzeremo il segreto in Vault.

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

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

    2. In questo esempio utilizzeremo l'engine segreto chiave/valore per memorizzare i dati.

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

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

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

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

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

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

    2. Attiva 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 il criterio all'account di servizio

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

    Qui assumiamo 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 quel nome.

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

      exit

  5. Installa il driver CSI del repository di secret

    # 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 SecretProviderClass Kubernetes che fa riferimento al secret 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 il yaml

    kubectl apply -f spc-vault.yaml

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

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

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

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

  10. Applica le modifiche:

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

Upgrade di Apigee hybrid

Dovresti aver completato tutti i requisiti indicati nella sezione Prerequisiti. Inoltre, ti consigliamo di eseguire un riavvio graduale di tutti i componenti per verificare se il cluster è integro. L'ordine dei riavvii 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 corrente.

    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 gli scenari di emergenza.

Esegui l'upgrade della piattaforma Kubernetes, se necessario

Questo passaggio non è necessario ogni volta, ma dovrai eseguire l'upgrade della piattaforma Kubernetes, come kubernetes, openshift e componenti come cert-manager, cassandra e così via, se non è più supportata 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 di Apigee hybrid 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 della cartella di configurazione di Apigee Hybrid:

  2. sostituisci la cartella di inizializzazione, degli strumenti e del controller nella configurazione di Apigee hybrid esistente.

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

Aggiorna le autorizzazioni dell'account di servizio, se necessario

Anche questo passaggio non è necessario ogni volta, ma se necessario dovrai creare un nuovo account di servizio o aggiornare le autorizzazioni degli account di servizio esistenti. La guida all'upgrade fornirà i dettagli su quali service account devono essere modificati o creati e quali sono i ruoli da aggiungere.

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

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

  • Se la versione ibrida di apigee più recente 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 dello strumento per creare nuovi account di servizio. Poiché lo script sarà già aggiornato nel 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 indicato nella RP 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 in base alla versione ibrida pertinente.

Ecco un file di esempio $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 procedura descritta in Creare 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 all'introduzione di nuovi campi o al ritiro di vecchi campi, dovrai modificare le RP con le modifiche appropriate in base alle istruzioni fornite nella guida all'upgrade. - Come minimo, devi aggiornare i campi della versione all'interno dei CR (che indicano la versione di Apigee hybrid installata) alla versione più recente di Apigee hybrid.

Applica le modifiche per le richieste apigee. Per l'ambiente non di produzione, puoi applicare contemporaneamente tutte le modifiche ai componenti apigee

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

Rollback di Apigee Hybrid

  1. Ripristina apigee-hybrid-setup

    Vai alla directory contenente la versione precedente della configurazione di Apigee Hybrid. Se non è disponibile, ripristinalo dal file ZIP creato nel passaggio 1[link] durante l'upgrade ad apigee hybrid.

  2. Esegui il rollback dei componenti Kubernetes

    Applica le modifiche per le richieste di aggiornamento Apigee

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

  3. Controller di rollback

    Segui la stessa procedura per creare risorse e controller di inizializzazione 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 e del controller di inizializzazione.

  4. Esegui la pulizia

    Dovrai ripulire le nuove risorse aggiuntive create durante l'upgrade, ad esempio i nuovi componenti o gli account di servizio introdotti nella versione più recente di Hybrid. Nella guida all'upgrade verranno fornite informazioni su tutte le risorse da ripulire e sulla procedura da seguire.

Eliminazione di un ambiente

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

  1. Recupera il nome della richiesta di modifica dell'ambiente. Per farlo, ottieni 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 dell'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 gli account di servizio 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 relative ad apigee hybrid dal cluster Kubernetes:

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

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

  2. Dovrai eliminare i componenti del dataplane ibrido apigee di cui è stato eseguito il deployment. Usa il seguente comando per eliminare tutti i componenti:

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

  3. Questo passaggio è necessario solo se non hai utilizzato il nome predefinito per i secret degli account di servizio Kubernetes, per i secret degli account di servizio Google Cloud e così via. Se hai utilizzato i nomi predefiniti, questi verranno eliminati nel passaggio successivo, altrimenti 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. In caso di OpenShift, dovrai eliminare le limitazioni del contesto di sicurezza (Security Context Constraints, SCC) create durante l'installazione di Apigee hybrid.

    kubectl delete scc ${SECURITY_CONTEXT_CONSTRAINTS_NAME}

  5. Esegui il comando seguente per eliminare ruoli, associazioni di ruoli, 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 seguente per eliminare il namespace apigee

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

    In alternativa, utilizza il comando:

    kubectl delete $APIGEE_NAMESPACE

Installazione multi-istanza

La configurazione di più istanze si riferisce alla configurazione ibrida che può essere estesa a 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 multi-regione, ti consigliamo di configurare una seconda regione in modalità di attesa attiva con dimensioni e configurazioni diverse.

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

Struttura della cartella 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 ibrida, devi aver completato i seguenti prerequisiti:

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

Puoi utilizzare uno strumento come ntpdate per verificare che le ore del server siano sincronizzate.

Configura l'host seed multi-region

  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 di instance1.
  3. Segui i passaggi descritti in Specificare i certificati TLS di ingresso per modificare la configurazione di ingresso per l'altra istanza.

  4. Per informazioni su come configurare l'IP del bilanciatore del carico per l'altra istanza, consulta la sezione Gestire il gateway di ingresso Apigee.

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

    kubectl config use-context original-cluster-name

  6. Esegui il seguente comando kubectl per identificare un indirizzo host iniziale per Cassandra nella regione corrente.

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

  7. Qualsiasi indirizzo IP del pod restituito dal comando precedente può essere considerato come host seed multiregione.

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

Configura la nuova istanza

  1. Imposta il contesto sul cluster esistente

    kubectl config use-context existing-cluster-name

  2. Esporta il 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 hybrid nella nuova istanza (regione) seguendo i passaggi descritti in Creare 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 YAML (risorsa personalizzata) per la replica dei dati di Cassandra. Il file può avere qualsiasi nome. Nei seguenti esempi, 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 assegni a questi metadati. Puoi scegliere un nome come "cassandra-data-replication"
    • NAMESPACE è lo stesso spazio dei nomi scelto per la seconda istanza. Di solito è "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 data center 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 ricostruzione utilizzando il seguente comando.

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

    Il risultato dovrebbe essere simile al seguente

    {
"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 le procedure di ricostruzione dai log. Verifica anche 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 seguente per applicare la modifica

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

  12. Controlla lo stato del cluster Cassandra

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

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


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

Risoluzione dei problemi

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

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

Pulizia manuale dopo l'utilizzo di forceDelete nella configurazione di Apigee Hybrid in più regioni

  • Nell'esempio seguente sono presenti due regioni: us-east1 e us-west1.
  • Nella regione us-west1, il datastore apigee è stato eliminato utilizzando l'eliminazione forzata.
  • Nella regione us-east1, Cassandra è ancora in esecuzione.

  • Verifica che apigeeds venga eliminato utilizzando il comando

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

  • Modifica il contesto kubectl nell'altra regione in cui il cluster Cassandra è ancora attivo (qui us-east1).

  • Verifica che il data store sia in stato di esecuzione

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

  • Esegui in uno dei pod Cassandra nella regione up (qui 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 (qui us-west1)

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

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

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

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

  • Verifica che non siano rimasti nodi della regione eliminata (qui us-west1)

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


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

  • Al termine, 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 dell'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 chiavi non abbiano la regione eliminata.

  • Crea un pod di debug di Cassandra.

    • Segui la versione ibrida 1.5 e versioni successive, segui la documentazione della guida alla risoluzione dei problemi di Cassandra (ad es. per la versione ibrida 1.5 - link, versione ibrida 1.6 - link) ed esegui nel 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 chiavi

    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)