Guida utente di anteprima:
Anteprima delle nuove procedure di installazione e amministrazione per Apigee hybrid v1.8.
In questo documento:
- Anteprima
- Panoramica
- Prerequisiti
- Installazione di base di Apigee Hybrid
- Installazione personalizzata di Apigee Hybrid
- Scaricare i file di configurazione
- Crea spazio dei nomi
- (Facoltativo) Utilizzo di immagini Docker da repository privati
- (Facoltativo) Configurare imagePullSecrets
- (Facoltativo) Configurazione del proxy di inoltro
- Specifica dei certificati TLS in entrata
- Aggiorna il deployment in entrata
- Configurazione di service account Google Cloud personalizzati
- Utilizzo delle identità dei carichi di lavoro
- Modifica i file YAML delle risorse
- Crea risorse di inizializzazione e controller
- Concedi le autorizzazioni al account di servizio di Synchronizer per interagire con il control plane
- Crea i componenti del data plane Apigee
- Attendi l'avvio delle risorse
- Personalizzare l'installazione di cert-manager in uno spazio dei nomi personalizzato
- Kustomize e componenti
- Concepts
- Comprendere lo script
- Struttura delle cartelle di configurazione di Apigee Hybrid
- Archiviazione delle chiavi dell'account di servizio in vault esterni
- Apigee Hybrid Upgrade
- Rollback di Apigee Hybrid
- Pulisci
- Eliminazione di un ambiente
- Installazione di più istanze
Anteprima
Questo documento è destinato alla persona dell'operatore Apigee (utenti che installano/gestiscono/amministrano le installazioni di Apigee hybrid). L'esperienza nell'installazione di Apigee Hybrid su una delle piattaforme Kubernetes supportate è un prerequisito per seguire le istruzioni riportate in questo documento. Ti consigliamo di creare un'organizzazione Apigee di valutazione per provare i passaggi riportati di seguito.
Feedback
Invia un feedback su questa procedura all'indirizzo Apigee-hybrid-install-preview@google.com.
Panoramica
La nuova esperienza di installazione di Apigee Hybrid installa i componenti Apigee utilizzando kubectl e integra l'installazione e la gestione di Apigee Hybrid con strumenti di orchestrazione della configurazione Kubernetes come Kustomize. Le convalide e la visibilità migliorate dei componenti in fase di installazione offrono una migliore capacità di debug e migliorano il processo di installazione complessivo.
Uno script di installazione, apigee-hybrid-setup.sh
, fornisce uno strumento semplice per l'installazione di base. Puoi utilizzarlo per creare l'installazione ibrida e poi modificarla in base alle tue esigenze con kubectl
oppure puoi creare l'installazione ibrida da zero utilizzando kubectl
.
Tutte le proprietà di configurazione di Apigee hybrid sono archiviate in file YAML, uno per ogni componente principale. Ciò consente un controllo molto più granulare dell'installazione ibrida nell'ambiente Kubernetes. Puoi trovare i file di configurazione e gli script di installazione nel repository su GitHub.
Modifiche alla nuova procedura di installazione
Apigee sta modificando la procedura di installazione di Apigee hybrid per i seguenti motivi:
- Il nuovo metodo di installazione di Apigee hybrid può essere integrato con gli strumenti CI/CD Kubernetes esistenti come Argo, Flux o Anthos Config Management, che non utilizzano un file di configurazione
overrides.yaml
. - Apigee hybrid ha fornito
apigeectl
, uno strumento di modelli personalizzato che genera manifest Kubernetes (tra le altre cose) per installare e gestire Apigee hybrid nei cluster Kubernetes. Il nuovo processo di installazione e gestione offre un'esperienza simile a quella di altri fornitori di software. - Il nuovo processo consente un'installazione di base rapida creando automaticamente service account con le autorizzazioni richieste, certificati TLS, precompilando i valori predefiniti e altri elementi di base necessari.
Prerequisiti
Prima di utilizzare questa installazione di anteprima, devi soddisfare i seguenti prerequisiti:
Versione di anteprima
Questa anteprima è pensata per funzionare con Apigee hybrid versione 1.8.x. Le versioni successive di Apigee Hybrid non sono supportate.
Configurazione di Apigee hybrid
Prima di procedere con l'installazione effettiva di Apigee Hybrid, devi aver completato le seguenti istruzioni elencate nelle sezioni successive della documentazione:
- Configurazione di progetto e organizzazione
- Panoramica per i prerequisiti per l'installazione di Apigee hybrid.
- Passaggio 1: attiva le API
- Passaggio 2: crea un'organizzazione
- Passaggio 3: crea un ambiente e un gruppo di ambienti
- Configurazione del runtime di hybrid
Strumenti
Inoltre, devi scaricare e configurare i seguenti strumenti sulla workstation:
curl
docker
è necessario per eseguire lo scriptapigee-hybrid-setup.sh
. Segui le istruzioni riportate in Get Docker per installare Docker.envsubst
dovrebbe essere disponibile nella maggior parte dei sistemi basati su Linux/UNIX. Per macOS e altri sistemi, segui le istruzioni riportate in questo repository.jq
deve essere installato. Scarica jq.kpt
Scarica kpt.kubectl
versione 1.23 o successive. Consulta la sezione Install Tools: kubectl nella documentazione di Kubernetes.
Variabili comuni utilizzate in questa guida
Questa guida utilizza le seguenti variabili di ambiente in diversi passaggi. Puoi definirli nella riga di comando o con uno script oppure puoi sostituire il testo nei comandi quando li inserisci.
APIGEE_NAMESPACE
: il tuo spazio dei nomi Apigee. Per impostazione predefinita, questo valore èapigee
. Tuttavia, puoi utilizzare uno spazio dei nomi diverso.CLUSTER_NAME
: il nome del cluster in cui stai installando Apigee hybrid. Questo è il cluster che crei nel passaggio 1: crea un cluster.CLUSTER_LOCATION
: la regione del cluster. Le procedure descritte in questa guida presuppongono l'utilizzo di un cluster regionale. Se utilizzi un cluster di zona, consulta le istruzioni riportate in Passaggio 1: crea un clusterENV_GROUP
: il nome del gruppo di ambienti per l'installazione di Apigee hybrid. Questo è il gruppo di ambienti che crei nel passaggio 3: crea un gruppo di ambienti. Puoi creare più gruppi di ambienti.ENV_NAME
: il nome del gruppo di ambienti per l'installazione di Apigee hybrid. Questo è il gruppo di ambienti che crei nel passaggio 3: crea un gruppo di ambienti. Puoi creare più gruppi di ambienti.INSTALL_DIR
: la directory in cui installi Apigee hybrid. Per impostazione predefinita, si tratta della sottodirectoryapigee-hybrid-install/
della directory in cui scarichi il programma di installazione, ad esempio:/myhybrid/apigee-hybrid-install/
. Questa è la directory principale per la struttura dei file documentata in Struttura delle cartelle di configurazione di Apigee Hybrid.INSTANCE_DIR
: la directory per un'istanza Apigee hybrid specifica. Per impostazione predefinita, la prima istanza si chiamainstance-1
. La directory dell'istanza è una sottodirectory di${INSTALL_DIR}/overlays/instances/
. Puoi specificare qualsiasi nome per le istanze ibride. Consulta la sezione Installazione di più istanze.ORG_NAME
: il nome della tua organizzazione Apigee hybrid. Deve essere uguale all'ID progetto Google Cloud. Vedi: Passaggio 2: crea un'organizzazione.
Installazione di base di Apigee hybrid
Per installare rapidamente Apigee Hybrid senza personalizzazioni complesse, puoi utilizzare la seguente procedura in due passaggi.
- Un unico ambiente
- Un singolo gruppo di ambienti
- Viene creato e utilizzato un unico account di servizio Google Cloud per tutti i singoli componenti
- Valori predefiniti per tutte le chiavi di crittografia e le password.
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
:
Clona il repository:
git clone https://github.com/apigee/apigee-hybrid-install.git
Vai alla directory del repository clonato:
cd apigee-hybrid-install
Crea un branch dal tag preview-1:
git branch preview-1 preview-1 git checkout preview-1
Rendi eseguibile lo script di configurazione:
chmod +x ./tools/apigee-hybrid-setup.sh
Il repository clonato avrà una struttura simile a quella descritta in Struttura delle cartelle di configurazione di Apigee Hybrid:
Esegui configurazione
Esegui lo script shell apigee-hybrid-setup.sh
che si trova nella cartella tools/
.
./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION --org $ORG_NAME --setup-all
Se riscontri errori, prova a eseguire lo script una seconda volta.
Altre opzioni che potresti voler utilizzare sono:
--env $ENV_NAME
specifica il nome dell'ambiente Apigee.--envgroup $ENV_GROUP
specifica il gruppo di ambienti.--ingress-domain $HOSTNAME
specifica il nome host che hai fornito per il gruppo di ambienti.--gcp-project-id $PROJECT_ID
specifica l'ID del tuo progetto Google Cloud.
Per ulteriori opzioni, consulta Informazioni sullo script.
Eventuali errori durante l'esecuzione verranno stampati nell'output standard.
Una volta completato correttamente lo script, l'installazione ibrida di base sarà terminata. Puoi testare l'installazione creando un proxy di esempio come descritto in Creazione e deployment di un nuovo proxy API.
Installazione personalizzata di Apigee Hybrid
Gli utenti più esperti che desiderano un controllo granulare sull'installazione possono seguire questa sequenza di passaggi (per molti dei passaggi riportati di seguito, puoi scegliere di eseguire il passaggio manualmente o utilizzare lo script shell per automatizzare il singolo passaggio):
Scaricare i file di configurazione
Scarica e prepara i file di configurazione:
Clona il repository GitHub all'indirizzo
https://github.com/apigee/apigee-hybrid-install/
Il repository clonato avrà una struttura simile a quella descritta in Struttura delle cartelle di configurazione di Apigee Hybrid:
cd
nella directoryapigee-hybrid-install/
Rendi eseguibile lo script di configurazione:
chmod +x ./tools/apigee-hybrid-setup.sh
Crea spazio dei nomi
Crea uno spazio dei nomi Kubernetes nel tuo cluster che conterrà tutti i componenti del cluster Apigee.
kubectl create namespace apigee
Se scegli un altro nome per lo spazio dei nomi, puoi scegliere di seguire una delle tre opzioni riportate di seguito:
- (Consigliato) Utilizza
--namespace={YOUR_NAMESPACE_NAME}
durante il precompilamento dei valori in Modifica i file YAML delle risorse. Esegui questi due comandi:
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
Utilizza
sed
per sostituire lo spazio dei nomi in istio discoveryAddress:sed -i -E -e "s/(discoveryAddress: apigee-ingressgateway-manager\.).*(\.svc:15012)/\1${APIGEE_NAMESPACE}\2/" "${INSTALL_DIR}/overlays/controllers/istiod/apigee-istio-mesh-config.yaml"
In alternativa, puoi modificare manualmente le risorse singolarmente per crearle nello spazio dei nomi che preferisci.
Utilizzo di immagini Docker da repository privati (facoltativo)
Puoi scegliere di non utilizzare le immagini ospitate pubblicamente e utilizzare immagini dei tuoi repository privati:
- Il primo passaggio consiste nel eseguire il push di tutte le immagini nel repository privato, il che può essere fatto seguendo i passaggi descritti in apigee-pull-push | Apigee X. Per impostazione predefinita, le immagini vengono taggate con la versione di Apigee Hybrid a cui corrispondono ed è consigliabile non modificare questi tag. Ti consigliamo inoltre di non modificare i nomi delle immagini in modo che il percorso finale dell'immagine possa essere creato come spiegato in Image Hub.
Imposta il valore del campo
imageHub
presente nel file apigee-hybrid-config.yaml sul percorso host del repository privato. Per maggiori dettagli, consulta l'hub delle immagini.imageHub: "your.private.repo/apigee/hybrid"
In questo modo, tutti i componenti di Apigee Hybrid utilizzano le immagini del tuo repository privato.
Oltre a questo, potresti anche voler utilizzare un'immagine privata per il controller e il gateway in entrata Apigee, per i quali dovrai modificare i file apigee-controller-deployment.yaml e apigee-ingressgateway-manager-deployment.yaml e sostituire tutti i campi image
con l'immagine del repository privato.
Configurazione di imagePullSecrets (facoltativa)
- Crea un secret di Kubernetes contenente le credenziali per l'autenticazione con i repository privati. Consulta Recuperare un'immagine da un registro privato per capire come deve essere creato il secret.
- Una volta creato il secret, non resta che farvi riferimento. Per farlo, modifica il file apigee-hybrid-config.yaml, imposta il valore del campo
imagePullSecret
sul nome del secret creato in precedenza e attiva il componenteimagePullSecret
nel filekustomization.yaml
corrispondente.
Se specifichi imagePullSecrets
in entrambi i punti, avrà la precedenza quello presente nel file apigee-controller-manager.yaml.
(Facoltativo) Configurazione del proxy di inoltro
I proxy di inoltro possono essere configurati aggiungendo il campo forwardProxy
al file apigee-hybrid-config.yaml
. Ad esempio:
forwardProxy: |
scheme: HTTP
host: 10.12.0.47
port: 3128
Specificare i certificati TLS in entrata
Utilizzare lo script
./tools/apigee-hybrid-setup.sh --create-ingress-tls-certs
Refer - Understanding the script per ulteriori dettagli su questo flag.
Manuale
Devi fornire i certificati TLS che verranno utilizzati per il gateway in entrata Istio. Puoi:
- utilizza certificati firmati da un'autorità nota seguendo i passaggi descritti in Ottenere certificati TLS: un esempio | Apigee X
- o generare certificati autofirmati.
Qui utilizzeremo i certificati autofirmati come esempio. I certificati autofirmati possono essere generati utilizzando (supponendo che DOMAIN
sia stato impostato correttamente e corrisponda al nome host impostato nel tuo gruppo di ambienti):
openssl req -nodes -new -x509 -keyout ./tls.key -out ./tls.crt -subj '/CN='$DOMAIN'' -days 3650
Verranno creati due file denominati tls.key
e tls.crt
.
Devi quindi creare un secret con il seguente formato. Puoi utilizzare kubectl create
o kubectl apply
come spiegato in Utilizzo di una coppia di certificato/chiave personalizzata per l'autorità di firma del certificato (facoltativo):
apiVersion: v1
kind: Secret
metadata:
name: "{ORG_NAME}-{ENV_GROUP_NAME}"
namespace: {$APIGEE_NAMESPACE}
type: Opaque
data:
cert: |
{BASE64_ENCODED_TLS_CRT}
key: |
{BASE64_ENCODED_TLS_KEY}
---
Esempio di creazione del secret utilizzando kubectl create
:
kubectl create secret tls {ORG_NAME}-{ENV_GROUP_NAME} \
--cert="tls.crt" \
--key="tls.key" \
-n {$APIGEE_NAMESPACE}
Aggiorna il deployment di Ingress
Per creare/modificare i deployment Ingress, devi modificare il campo spec.components.ingressGateways
nella risorsa personalizzata ApigeeOrganization in bases/initialization/crds/customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
.
Per impostazione predefinita, creiamo un deployment in entrata con parametri predefiniti(i valori predefiniti verranno visualizzati nella documentazione di riferimento CR ):
ingressGateways:
- name: "prod-1"
Esempi:
A. Override dei campi del servizio di ingresso
ingressGateways:
- name: "prod-1"
serviceSpec:
annotations:
{KEY}: ${VALUE}
loadBalancerIP: ${IP}
B. Modifica il numero minimo/massimo di repliche
ingressGateways:
- name: "prod-1"
autoScaler:
minReplicas: 4
maxReplicas: 10
C. Aggiunta di un nuovo deployment Ingress
ingressGateways:
- name: "prod-1"
- name: "prod-2"
Configurazione di service account Google Cloud personalizzati
Utilizzare lo script
./tools/apigee-hybrid-setup.sh --create-gcp-sa-and-secrets --namespace APIGEE_NAMESPACE
Dove APIGEE_NAMESPACE è il tuo spazio dei nomi personalizzato. Lo spazio dei nomi predefinito è apigee
.
Per ulteriori dettagli sui flag, consulta la sezione Informazioni sullo script.
Manuale
Le chiavi del account di servizio Google Cloud devono essere archiviate come secret nel cluster. Il file YAML del secret deve avere la seguente struttura:
apiVersion: v1
kind: Secret
metadata:
name: "{NAME}"
namespace: {APIGEE_NAMESPACE}
type: Opaque
data:
client_secret.json: |
{BASE64_ENCODED_SA_KEY}
Per ulteriori dettagli su tutti i service account richiesti e sui nomi dei secret, consulta la sezione Service account Google Cloud.
Puoi scegliere un nome diverso per i secret, ma dovrai apportare una modifica corrispondente nel componente in cui è stato utilizzato il nome del secret. Ad esempio, se decidi di modificare il nome del secret del account di servizio di runtime da apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME}
a my-runtime-svc
, dovrai apportare una modifica corrispondente in apigee-environment.yaml
per quell'ambiente.
Utilizzo delle identità dei carichi di lavoro
Una delle due opzioni, Configurazione di service account Google Cloud personalizzati o Utilizzo delle identità del carico di lavoro, è obbligatoria.
Prerequisiti
Prima di utilizzare le identità del workload, assicurati che il supporto sia abilitato nel tuo cluster GKE. Per maggiori dettagli, consulta Aggiornamento dei pool di nodi | Apigee X.
Abilitazione di workload-identity
Per informazioni dettagliate su come abilitare le identità dei workload prima dell'installazione, consulta la sezione Identità dei workload in Kustomize e componenti.
Modifica i file YAML delle risorse
Alcuni punti dei file YAML dei componenti richiedono la presenza dei nomi corretti di organizzazione, ambiente e gruppo di ambienti. Puoi impostare questi valori manualmente o utilizzare lo script shell per compilarli automaticamente.
Utilizzare lo script
./tools/apigee-hybrid-setup.sh --fill-values
Crea risorse di inizializzazione e controller
#Additional steps for openshift
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/openshift
//apigee datastore
kubectl apply -f ${INSTANCE_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/components/openshift-scc/scc.yaml
//telemetry
kubectl apply -f ${INSTANCE_DIR}/overlays/instances/${INSTANCE_DIR}/telemetry/components/openshift-scc/scc.yaml
#Create Apigee initialization kubernetes resources
kubectl apply -f ${INSTALL_DIR}/overlays/initialization/namespace.yaml
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/certificates
kubectl apply --server-side --force-conflicts -k ${INSTALL_DIR}/overlays/initialization/crds
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/webhooks
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/rbac
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/ingress
# Create controller config and controller
kubectl apply -k ${INSTALL_DIR}/overlays/controllers
# Wait for the controllers to be available
kubectl wait deployment/apigee-controller-manager deployment/apigee-ingressgateway-manager -n "${APIGEE_NAMESPACE}" --for=condition=available --timeout=2m
# Create the datastore and redis secrets first and then the rest of the secrets.
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/redis/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/${ENV_NAME}/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/organization/secrets.yaml
Concedi le autorizzazioni al account di servizio di Synchronizer per interagire con il control plane
Segui i passaggi descritti in Passaggio 8: attiva l'accesso al sincronizzatore,
sostituendo il nome dell'account di servizio, apigee-non-prod
o apigee-synchronizer
, con
apigee-all-sa
, il nome dell'account di servizio creato dalla nuova procedura di installazione.
★ Importante: assicurati di modificare il nome del account di servizio nelle istruzioni riportate in Attivare l'accesso al sincronizzatore. In caso contrario, l'attivazione dell'accesso per il sincronizzatore non andrà a buon fine.
Crea i componenti del piano dati Apigee
Se hai modificato i nomi di una delle risorse nei passaggi precedenti, dovrai apportare una modifica corrispondente in altri file YAML in cui è stata fatto riferimento a quella risorsa. Una volta fatto, utilizza i comandi nell'esempio seguente:
# Create the rest of the resources.
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
per installare tutti i componenti.
Attendi l'avvio delle risorse
kubectl wait "apigeedatastore/default" \
"apigeeredis/default" \
"apigeeenvironment/${ORG_NAME}-${ENV_NAME}" \
"apigeeorganization/${ORG_NAME}" \
"apigeetelemetry/apigee-telemetry" \
-n "${APIGEE_NAMESPACE}" --for="jsonpath=.status.state=running" --timeout=15m
Personalizzare l'installazione di cert-manager in uno spazio dei nomi personalizzato
Personalizza lo spazio dei nomi in cui viene eseguito cert-manager con la seguente procedura.
Se cert-manager è installato nel cluster in uno spazio dei nomi diverso da cert-manager, dovrai aggiornare lo spazio dei nomi utilizzato per creare il certificato radice Apigee.
- Modifica il file customization.yaml per la creazione del certificato:
$INSTALL_DIR/overlays/initialization/certificates/kustomize.yaml
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
Salva il file.
Kustomize e componenti
Panoramica
La nuova installazione ibrida eredita l'ideologia di Kustomize di strutturare i file YAML sotto forma di basi e overlay.
- Le basi sono file forniti da Apigee, che potrebbero cambiare a ogni nuova release di Hybrid. Non è previsto che tu modifichi questi file. Questi file contengono alcuni valori predefiniti forniti da Apigee. Tutti i file nella cartella di primo livello
bases/
contengono queste basi Gli overlay contengono la configurazione utente e fungono da mezzo per modificare i valori predefiniti specificati nelle basi. Tutti i file nella cartella di primo livello
overlays/
contengono queste sovrapposizioni
Come utilizzare i componenti
Le sottocartelle all'interno della directory overlays/
di primo livello sono state strutturate in modo tale da poter attivare (o disattivare) una determinata funzionalità aggiuntiva commentando (o decommentando) alcune righe nei file kustomization.yaml
.
Ad esempio, ecco come appare la struttura delle cartelle overlays/instances/{INSTANCE_NAME}/telemetry
:
telemetry
├── components
│ ├── http-proxy
│ ├── imagepullsecret
│ ├── logger
│ ├── metrics
│ ├── nodeselector
│ ├── openshift-scc
│ ├── workload-identity-logger
│ └── workload-identity-metrics
├── apigee-telemetry.yaml
└── kustomization.yaml
Ecco come si presenterebbero probabilmente i file telemetry/kustomization.yaml
per impostazione predefinita:
resources:
- apigee-telemetry.yaml
components:
- ./components/metrics
# - ./components/workload-identity-metrics
# - ./components/logger
# - ./components/workload-identity-logger
# - ./components/http-proxy
# - ./components/nodeselector/
# - ./components/imagepullsecret
# - ./components/openshift-scc
Ci risulta che ./components/logger
è stato commentato, il che significa semplicemente che non abbiamo attivato uGoogle Clod Logger per impostazione predefinita. Per attivarlo, puoi semplicemente rimuovere il commento dalla riga come segue:
components:
- ./components/logger
Allo stesso modo, per disattivare le metriche, puoi commentare la riga ./components/metrics
:
...
components:
...
# - ./components/metrics
…
Le sezioni seguenti descriveranno tutti questi vari componenti, quando possono essere utilizzati e come possono essere configurati.
OpenShift
Per gli utenti che vogliono installare Apigee Hybrid in un cluster OpenShift
, potrebbe essere necessario abilitare alcuni componenti/risorse prima di eseguire l'installazione. Questo passaggio è obbligatorio se non utilizzi lo script per eseguire l'installazione. I file da modificare sono:
overlays/initialization/openshift/kustomization.yaml
. Nella sezioneresources:
, rimuovi il commento da:# - ../../../bases/initialization/openshift/
overlays/instances/{INSTANCE_NAME}/datastore/kustomization.yaml
Rimuovi il commento:# - ./components/openshift-scc
e rimuovi il commento dal campo "
components:
" se è ancora commentato.overlays/instances/{INSTANCE_NAME}/telemetry/kustomization.yaml
Rimuovi il commento:# - ./components/openshift-scc
e rimuovi il commento dal campo "
components:
" se è ancora commentato.
A questo punto puoi procedere con i passaggi di installazione.
imagepullsecret
Questo componente può essere abilitato quando hai immagini archiviate nel tuo repository privato. Per eseguire il pull delle immagini da un repository privato, puoi creare un secret Kubernetes che contenga i dettagli di autenticazione e a cui puoi fare riferimento all'interno. Per le istruzioni, vedi Configurazione di imagePullSecrets (facoltativo). Per ulteriori informazioni, consulta Pull an Image from a Private Registry | Kubernetes nella documentazione di Kubernetes.
Disponibile in:
overlays/controllers/apigee-controller
overlays/controllers/istiod
overlays/instances/{INSTANCE_NAME}/datastore
overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
overlays/instances/{INSTANCE_NAME}/organization
overlays/instances/{INSTANCE_NAME}/redis
overlays/instances/{INSTANCE_NAME}/telemetry
Attivazione in corso:
Rimuovi il commento dalla riga "./components/imagepullsecret/
" nei rispettivi file kustomization.yaml
, se necessario.
Modifiche da apportare:
- components/imagepullsecret/patch.yaml
- OBBLIGATORIO Aggiungi i nomi dei segreti pertinenti all'elenco in
spec.template.spec.imagePullSecrets
.
- OBBLIGATORIO Aggiungi i nomi dei segreti pertinenti all'elenco in
Utilizzo:
- Se non hai ancora installato Apigee Hybrid, puoi continuare con i passaggi di installazione e queste modifiche verranno applicate durante la procedura
Se hai già installato Apigee Hybrid, dovrai applicare queste nuove modifiche utilizzando:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
nodeselector
Questo componente ti consente di pianificare i pod per una risorsa Apigee su nodi specifici. Per ulteriori informazioni, consulta Assegnazione di pod ai nodi | Kubernetes.
Disponibile in:
overlays/controllers/apigee-controller
overlays/controllers/istiod
overlays/instances/{INSTANCE_NAME}/datastore
overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
overlays/instances/{INSTANCE_NAME}/organization
overlays/instances/{INSTANCE_NAME}/redis
overlays/instances/{INSTANCE_NAME}/telemetry
Attivazione in corso:
Rimuovi il commento dalla riga "./components/nodeselector
" nei rispettivi file kustomization.yaml
, se necessario.
Modifiche da apportare:
- components/nodeselector/patch.yaml
- (FACOLTATIVO) Modifica il valore dell'etichetta del selettore di nodi da
apigee-runtime
oapigee-data
a quello desiderato.
- (FACOLTATIVO) Modifica il valore dell'etichetta del selettore di nodi da
Utilizzo:
- Se non hai ancora installato Apigee Hybrid, puoi continuare con i passaggi di installazione e queste modifiche verranno applicate durante la procedura
Se hai già installato Apigee Hybrid, dovrai applicare queste nuove modifiche utilizzando:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
workload-identity
Diversi container nell'ecosistema Apigee Hybrid richiedono autorizzazioni per effettuare determinate chiamate API al control plane / management plane di Apigee. Workload Identity è uno dei modi per concedere queste autorizzazioni ai pod (e ai container al loro interno). Ecco alcune risorse utili per saperne di più: - Introducing Workload Identity: Better authentication for your GKE applications | Google Cloud Blog - Use Workload Identity | Kubernetes Engine Documentation | Google Cloud
Disponibile in:
overlays/instances/{INSTANCE_NAME}/datastore
overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
overlays/instances/{INSTANCE_NAME}/organization
overlays/instances/{INSTANCE_NAME}/redis
overlays/instances/{INSTANCE_NAME}/telemetry
Prerequisito:
Prima di poter utilizzare Workload Identity, devi concedere le autorizzazioni pertinenti all'interno del tuo progetto Google Cloud utilizzando:
gcloud iam service-accounts add-iam-policy-binding \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:${ORG_NAME}.svc.id.goog[${APIGEE_NAMESPACE}/${KSA_NAME}]" \
${GSA_NAME}@${ORG_NAME}.iam.gserviceaccount.com
dove:
- ${ORG_NAME} - Il nome della tua organizzazione Apigee.
- ${APIGEE_NAMESPACE}: lo spazio dei nomi Kubernetes in cui sono stati installati i componenti Apigee. Di solito è apigee
, a meno che non sia stato modificato esplicitamente dall'utente durante l'installazione
- ${KSA_NAME} - Il nome dello spazio dei nomi Kubernetes. Devi eseguire questo comando per ogni account di servizio Kubernetes menzionato in Service account Kubernetes
- ${GSA_NAME} - Il nome del account di servizio Google Cloud. Se non hai apportato modifiche durante l'installazione, questo valore sarà apigee-all-sa
. Se configuri più account di servizio Google Cloud per singoli componenti, devi abbinare KSA_NAME al GSA_NAME corrispondente. Puoi confrontare le tabelle in Service account Google Cloud con Service account Kubernetes per trovare gli equivalenti.
Attivazione in corso:
Rimuovi il commento dalla riga ./components/workload-identity
nei rispettivi file kustomization.yaml
, se necessario. Tieni presente che all'interno della telemetria sono presenti componenti aggiuntivi di identità del workload separati per i componenti metrics
e logger
, che possono essere attivati singolarmente.
Utilizzo:
- Se non hai ancora installato l'ibrido, puoi semplicemente attivare l'identità del workload come indicato nella sezione precedente e continuare con l'installazione, che utilizzerà automaticamente l'identità del workload.
Se hai già installato Apigee Hybrid, dovrai applicare queste nuove modifiche utilizzando:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
http-proxy
Puoi configurare un server proxy in ciascuno dei seguenti componenti in modo che il traffico per quel componente passi attraverso il proxy HTTP configurato per quel componente. Puoi configurare il proxy per ogni componente Apigee singolarmente.
Disponibile in:
overlays/instances/{INSTANCE_NAME}/datastore
overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
overlays/instances/{INSTANCE_NAME}/organization
overlays/instances/{INSTANCE_NAME}/telemetry
Attivazione in corso:
Rimuovi il commento dalla riga "./components/http-proxy/
" nei rispettivi file kustomization.yaml
, se necessario.
Modifiche da apportare:
- components/http-proxy/patch.yaml
I seguenti parametri possono essere configurati in
spec.httpForwardProxy
scheme
: OBBLIGATORIO. Uno traHTTP
oHTTPS
host
: OBBLIGATORIO L'indirizzo host del proxyport
: OBBLIGATORIO Il numero di portausername
: FACOLTATIVO Il nome utente associato al proxypassword
: FACOLTATIVO La password per accedere al proxy
Utilizzo:
- Se non hai ancora installato Apigee Hybrid, puoi continuare con i passaggi di installazione e queste modifiche verranno applicate durante la procedura
Se hai già installato Apigee Hybrid, dovrai applicare queste nuove modifiche utilizzando:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
logger e metriche
Puoi attivare o disattivare singolarmente il logger o le metriche all'interno di sovrapposizioni/istanze/{INSTANCE_NAME}/telemetria. Per impostazione predefinita, il logger è disattivato e le metriche sono attivate. Per attivarli o disattivarli, è sufficiente rimuovere il commento o aggiungere un commento alle righe in telemetry/kustomization.yaml
gcs-backup e gcs-restore
Questo componente kustomize può essere utilizzato per eseguire un backup e un ripristino del database Cassandra in Google Cloud Storage.
Disponibile in:
overlays/instances/{INSTANCE_NAME}/datastore
Prerequisito:
Scarica le chiavi dei service account Google Cloud per un account con il ruolo Amministratore oggetti Storage.
- Se hai utilizzato lo script per eseguire l'installazione e non hai utilizzato workload identity, puoi riutilizzare le chiavi scaricate disponibili nella cartella service-accounts creata dallo script.
Puoi anche utilizzare lo script create-service-account.sh per creare un nuovo account di servizio e scaricarne le chiavi:
./tools/create-service-accounts=.sh --env prod --profile apigee‑cassandra
Una volta scaricate le chiavi, devi creare un secret Kubernetes con il nome apigee-cassandra-backup-and-restore-gcp-sa-key, che può essere creato utilizzando il comando:
kubectl create secret generic "apigee-cassandra-backup-and-restore-gcp-sa-key" \ --from-file="dbbackup_key.json=${PATH_TO_SA_KEY}" \ -n "${APIGEE_NAMESPACE}"
Dove:
- ${PATH_TO_SA_KEY}: percorso del file contenente le chiavi dell'account di servizio.
- ${APIGEE_NAMESPACE}: lo spazio dei nomi Kubernetes in cui sono stati installati i componenti Apigee. Di solito è apigee, a meno che non sia stato modificato esplicitamente durante l'installazione
In alternativa, puoi utilizzare il file modello templates/secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml per creare questo secret.
Attivazione in corso:
- Se vuoi attivare il backup, rimuovi il commento dalla riga "./components/gcs-backup" nel file datastore kustomization.yaml.
- Se vuoi ripristinare un backup, rimuovi il commento dalla riga "./components/gcs-restore" nel file datastore kustomization.yaml.
Modifiche solo per il backup
- components/gcs-backup/apigee-datastore-patch.yaml
- OBBLIGATORIO Modifica il valore della variabile di ambiente DATABASE_STORAGE_BUCKET, che avrà il formato gs://BUCKET_NAME e punterà al bucket Google Cloud Storage in cui devono essere eseguiti i backup dei dati. La descrizione corrisponde a dbStorageBucket descritto qui.
- components/gcs-backup/cron-patch.yaml
- OBBLIGATORIO Modifica spec.schedule per specificare la frequenza del backup. Il campo accetta il formato standard di pianificazione Crontab. La descrizione corrisponde alla programmazione descritta qui.
- OBBLIGATORIO Modifica il valore della variabile di ambiente DATABASE_STORAGE_BUCKET, che avrà il formato gs://BUCKET_NAME e punterà al bucket Google Cloud Storage in cui devono essere eseguiti i backup dei dati. La descrizione corrisponde a dbStorageBucket descritto qui.
- (FACOLTATIVO) Modifica il valore di HTTP_PROXY_URL in modo che punti a qualsiasi proxy configurato. Il formato potrebbe essere il seguente:
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS>:${HOST_PORT}
Esecuzione del backup
Puoi eseguire il backup con il seguente comando:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
Per applicare le modifiche e attivare il backup:
Modifiche solo per il ripristino
- components/gcs-restore/apigee-datastore-patch.yaml
- OBBLIGATORIO Modifica il valore della variabile di ambiente DATABASE_STORAGE_BUCKET, che avrà il formato gs://BUCKET_NAME e punterà al bucket Google Cloud Storage in cui devono essere eseguiti i backup dei dati. La descrizione corrisponde a dbStorageBucket descritto qui.
- components/gcs-restore/job-patch.yaml
- OBBLIGATORIO Modifica il valore della variabile di ambiente DATABASE_STORAGE_BUCKET, che avrà il formato gs://BUCKET_NAME e punterà al bucket Google Cloud Storage in cui devono essere eseguiti i backup dei dati.
- REQUIRED Modifica il valore della variabile di ambiente BACKUP_SNAPSHOT_TIMESTAMP. La descrizione corrisponde al ripristino:snapshotTimestamp descritto qui.
- (FACOLTATIVO) Modifica il valore di HTTP_PROXY_URL in modo che punti a qualsiasi proxy configurato.
Il formato potrebbe essere il seguente:
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
Esecuzione del ripristino:
Per informazioni di base sul ripristino dei backup, vedi Ripristino dei backup | Apigee X | Google Cloud
- Crea un nuovo cluster Kubernetes con un nuovo spazio dei nomi in cui ripristinare il deployment dell'ambiente di runtime ibrido. Non puoi utilizzare lo stesso cluster e lo stesso spazio dei nomi che hai utilizzato per l'installazione ibrida originale.
Installa Hybrid nel nuovo cluster con le impostazioni configurate sopra, oltre a qualsiasi altra impostazione che desideri:
- Puoi utilizzare l'installazione di base e installare hybrid nel nuovo spazio dei nomi:
./tools/apigee-hybrid-setup.sh \ --cluster-name $CLUSTER_NAME \ --cluster-region $CLUSTER_LOCATION \ --namespace ${NEW_APIGEE_NAMESPACE}
- In alternativa, segui la procedura di installazione personalizzata di Apigee Hybrid per configurare gli elementi in base alle tue preferenze.
Una volta completato il ripristino, tutte le risorse nel vecchio spazio dei nomi possono essere eliminate e trasferite al nuovo spazio dei nomi.
Per ulteriori informazioni, vedi Ripristinare i backup.
non-gcs-backup e non-gcs-restore
Questo componente kustomize può essere utilizzato per eseguire un backup e un ripristino del database Cassandra in Google Cloud Storage.
Disponibile in:
overlays/instances/{INSTANCE_NAME}/datastore
Prerequisito:
- È possibile utilizzare i passaggi della documentazione già esistente per configurare il server e SSH.
Dai passaggi precedenti, dovrai utilizzare la chiave privata SSH disponibile nel file "ssh_key" generato seguendo i passaggi precedenti. Verrà quindi creato un secret Kubernetes denominato apigee-cassandra-backup-and-restore-gcp-sa-key che contiene questa chiave privata SSH.
Il secret Kubernetes può essere creato utilizzando il seguente comando:
kubectl create secret generic "apigee-cassandra-backup-and-restore-key-file" \ --from-file="key=${PATH_TO_SSH_PRIVATE_KEY}" \ -n "${APIGEE_NAMESPACE}"
Dove:
- ${PATH_TO_SSH_PRIVATE_KEY}: percorso del file contenente la chiave privata SSH
- ${APIGEE_NAMESPACE}: lo spazio dei nomi Kubernetes in cui sono stati installati i componenti Apigee. Di solito è apigee, a meno che non sia stato modificato esplicitamente durante l'installazione
In alternativa, puoi utilizzare il file modello templates/secret-apigee-cassandra-backup-and-restore-key-file.yaml per creare questo secret.
Attivazione in corso:
- Se vuoi attivare il backup, rimuovi il commento dalla riga "
./components/non-gcs-backup
" nel file datastore kustomization.yaml. - Se vuoi ripristinare un backup, rimuovi il commento dalla riga "
./components/non-gcs-restore
" nel file datastore kustomization.yaml.
Modifiche solo per il backup
- components/non-gcs-backup/apigee-datastore-patch.yaml
- OBBLIGATORIO Modifica il valore di BACKUP_SERVER_IP. La descrizione corrisponde a BACKUP_SERVER_IP descritto qui.
- OBBLIGATORIO Modifica il valore di BACKUP_STORAGE_DIR. La descrizione corrisponde a BACKUP_STORAGE_DIR descritto qui.
- components/non-gcs-backup/cron-patch.yaml
- OBBLIGATORIO Modifica spec.schedule per specificare la frequenza del backup. Il campo accetta il formato standard di pianificazione Crontab. La descrizione corrisponde alla programmazione descritta qui.
- OBBLIGATORIO Modifica il valore di BACKUP_SERVER_IP. La descrizione corrisponde a BACKUP_SERVER_IP descritto qui.
- OBBLIGATORIO Modifica il valore di BACKUP_STORAGE_DIR. La descrizione corrisponde a BACKUP_STORAGE_DIR descritto qui.
- (FACOLTATIVO) Modifica il valore di HTTP_PROXY_URL in modo che punti a qualsiasi proxy configurato. Il formato potrebbe essere il seguente:
http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
Esecuzione del backup
Puoi eseguire il backup con il seguente comando:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
Per applicare le modifiche e attivare il backup:
Modifiche solo per il backup
- components/non-gcs-restore/apigee-datastore-patch.yaml
- OBBLIGATORIO Modifica il valore di
BACKUP_SERVER_I
P. La descrizione corrisponde aBACKUP_SERVER_IP
descritto qui. - OBBLIGATORIO Modifica il valore di BACKUP_STORAGE_DIR. La descrizione corrisponde a
BACKUP_STORAGE_DIR
descritto qui.
- OBBLIGATORIO Modifica il valore di
- components/non-gcs-restore/job-patch.yaml
- OBBLIGATORIO Modifica il valore della variabile di ambiente
BACKUP_SNAPSHOT_TIMESTAMP
. La descrizione corrisponde arestore:snapshotTimestamp
descritto qui. - REQUIRED Modifica il valore di
BACKUP_SERVER_IP
. La descrizione corrisponde aBACKUP_SERVER_IP
descritto qui. - REQUIRED Modifica il valore di
BACKUP_STORAGE_DIR
. La descrizione corrisponde aBACKUP_STORAGE_DIR
descritto qui. - (FACOLTATIVO) Modifica il valore di
HTTP_PROXY_URL
in modo che punti a qualsiasi proxy configurato. Il formato potrebbe essere il seguente:http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
http://${HOST_IP_ADDRESS}:${HOST_PORT}
- OBBLIGATORIO Modifica il valore della variabile di ambiente
Esecuzione del ripristino:
Per una panoramica del ripristino dei backup, consulta Panoramica del ripristino di Cassandra.
- Crea un nuovo cluster Kubernetes con un nuovo spazio dei nomi in cui ripristinare il deployment dell'ambiente di runtime ibrido. Non puoi utilizzare lo stesso cluster e lo stesso spazio dei nomi che hai utilizzato per l'installazione ibrida originale.
Installa Hybrid nel nuovo cluster con le impostazioni configurate sopra, oltre a qualsiasi altra impostazione che desideri: Puoi utilizzare l'installazione di base e installare Hybrid nel nuovo spazio dei nomi:
./tools/apigee-hybrid-setup.sh \ --cluster-name $CLUSTER_NAME \ --cluster-region $CLUSTER_LOCATION \ --namespace ${NEW_APIGEE_NAMESPACE}
In alternativa, segui la procedura di installazione personalizzata di Apigee Hybrid per configurare gli elementi in base alle tue preferenze.
Una volta completato il ripristino, tutte le risorse nel vecchio spazio dei nomi possono essere eliminate e trasferite al nuovo spazio dei nomi.
Per ulteriori informazioni, vedi Pianificare i backup su un server remoto.
http-client
Per istruzioni, vedi Attivare i client HTTP | Apigee.
Disponibile in:
- overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}
Attivazione in corso:
Rimuovi il commento dalla riga "./components/http-client
" nel file route-config/${ENV_GROUP}/kustomization.yaml
corrispondente
Modifiche da apportare:
- Non sono richieste modifiche obbligatorie.
Utilizzo:
- Se non hai ancora installato Apigee Hybrid, puoi continuare con i passaggi di installazione e queste modifiche verranno applicate durante la procedura
Se hai già installato Apigee Hybrid, dovrai applicare queste nuove modifiche utilizzando:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
non-sni-client
Equivalente alla How to configure a non-SNI client | Apigee esistente.
Disponibile in:
- overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}
Attivazione in corso:
Rimuovi il commento dalla riga "./components/non-sni-client
" nel file route-config/${ENV_GROUP}/kustomization.yaml
corrispondente
Modifiche da apportare:
- components/non-sni-client/apigee-route.yaml
- OBBLIGATORIO
credentialName
La descrizione corrisponde a quellacredential_name
descritta qui.
- OBBLIGATORIO
Utilizzo:
- Se non hai ancora installato Apigee Hybrid, puoi continuare con i passaggi di installazione e queste modifiche verranno applicate durante la procedura
Se hai già installato Apigee Hybrid, dovrai applicare queste nuove modifiche utilizzando:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
http-and-non-sni-client
Per istruzioni, vedi Abilitare il supporto per client non SNI e HTTP | Apigee.
Attivazione in corso:
Rimuovi il commento dalla riga "./components/http-and-non-sni-client
" nel file route-config/${ENV_GROUP}/kustomization.yaml
corrispondente
Modifiche da apportare:
- components/http-and-non-sni-client/apigee-route.yaml
- OBBLIGATORIO
credentialName
La descrizione corrisponde a quellacredential_name
descritta qui.
- OBBLIGATORIO
Utilizzo:
- Se non hai ancora installato Apigee Hybrid, puoi continuare con i passaggi di installazione e queste modifiche verranno applicate durante la procedura
Se hai già installato Apigee Hybrid, dovrai applicare queste nuove modifiche utilizzando:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
più regioni
Questo componente può essere utilizzato durante la configurazione di un deployment Cassandra multiregionale. Per maggiori informazioni, consulta Deployment in più regioni su GKE e GKE On-Prem.
Attivazione in corso:
Rimuovi il commento dalla riga "./components/multi-region
" nel file datastore/kustomization.yaml
Modifiche da apportare:
components/multi-region/cassandra-data-replication.yaml
- OBBLIGATORIO
source.region
Il nome del datacenter Cassandra di origine che verrà utilizzato per replicare i dati. Può essere identificato utilizzando il seguente comando nel cluster di origine:
kubectl get apigeedatastore -n ${APIGEE_NAMESPACE} -o=jsonpath='{.items[*].spec.components.cassandra.properties.datacenter}'
- OBBLIGATORIO
components/multi-region/patch.yaml
- OBBLIGATORIO
spec.components.properties.multiRegionSeedHost
L'IP pod di uno qualsiasi dei pod Cassandra di origine. Possiamo utilizzare:
kubectl get pods -n ${APIGEE_NAMESPACE} -o wide
- Per elencare tutti i pod e ottenere l'IP di qualsiasi pod Cassandra, utilizza il seguente comando:
kubectl get pods -o wide -n apigee
L'output dovrebbe essere simile al seguente:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE apigee-cassandra-default-0 1/1 Running 0 5d 10.0.0.11 gke-k8s-dc-2-default-pool-a2206492-p55d apigee-cassandra-default-1 1/1 Running 0 5d 10.0.2.4 gke-k8s-dc-2-default-pool-e9daaab3-tjmz apigee-cassandra-default-2 1/1 Running 0 5d 10.0.3.5 gke-k8s-dc-2-default-pool-e589awq3-kjch
- OBBLIGATORIO
Per maggiori informazioni, consulta Prerequisiti per GKE in "Deployment in più regioni su GKE, GKE On-Prem e AKS":
Utilizzo:
L'utilizzo di questo componente ha senso soprattutto quando configuri Apigee Hybrid in un nuovo cluster e hai già un'altra configurazione funzionante di Apigee Hybrid.
- Per garantire una comunicazione corretta tra i pod Cassandra, sia il cluster nuovo sia quello esistente devono utilizzare gli stessi certificati TLS. Pertanto, dovremo copiare il secret
apigee-root-certificate
dal cluster esistente e utilizzarlo anche in quello più recente: Esegui:
kubectl config get-contexts
- Per ottenere un elenco di tutti i contesti Kubernetes ed eseguire
kubectl config use-context SOURCE_CLUSTER_CONTEXT
dove SOURCE_CLUSTER_CONTEXT è il nome del contesto del cluster Kubernetes di origine.
Memorizza il segreto del certificato radice in un file:
kubectl get secret/apigee-root-certificate -n cert-manager -o yaml > apigee-root-certificate.yaml
Passa al contesto del nuovo cluster in cui stai installando Apigee Hybrid.
kubectl config use-context ${NEW_CLUSTER_CONTEXT}
Crea il secret principale nel nuovo cluster:
kubectl -n cert-manager apply -f apigee-root-certificate.yaml
Disattiva la creazione di un nuovo certificato radice. In questo modo, non creeremo un nuovo
apigee-root-certificate
e non sovrascriveremo quello creato nel passaggio precedente.Rimuovi il commento dalle seguenti righe nel file
overlays/initialization/certificates/kustomization.yaml
:# components: # - ./components/disable-apigee-root-certificate-generation
Continua con il resto dell'installazione di Apigee Hybrid utilizzando l'installazione di base di Apigee Hybrid o l'installazione personalizzata di Apigee Hybrid. Ad esempio, dopo l'installazione di base di Apigee Hybrid, puoi eseguire:
./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION
Verifica lo stato della ricompilazione utilizzando il seguente comando.
kubectl -n ${APIGEE_NAMESPACE} get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
Verifica i processi di ricompilazione dai log. Inoltre, verifica le dimensioni dei dati utilizzando il comando nodetool status:
kubectl logs apigee-cassandra-default-0 -f -n ${APIGEE_NAMESPACE} kubectl exec apigee-cassandra-default-0 -n ${APIGEE_NAMESPACE} -- nodetool -u ${JMX_USER} -pw ${JMX_PASSWORD} status
Verifica lo stato della ricompilazione utilizzando il seguente comando.
kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
I risultati dovrebbero essere simili a questi:
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }
Vedi anche: Deployment multiregionale.
Rimozione delle seguenti righe da
components/multi-region/patch.yaml
:properties: multiRegionSeedHost: {IP_ADDRESS} # To be modified. REQUIRED
Applica le modifiche:
kubectl apply -k overlays/instances/{INSTANCE_NAME}
Concetti
Hub delle immagini
Le immagini container Docker sono generalmente specificate nel formato:
${REGISTRY_HOST_PATH}/${IMAGE_NAME}:${IMAGE_TAG}
o quelli che utilizzano un riepilogo simile a questo:
${REGISTRY_HOST_PATH}/${IMAGE_NAME}@${DIGEST}
Apigee utilizza il concetto di "Image Hub", che nei formati precedenti si riferisce a ${REGISTRY_HOST_PATH}
. Il valore predefinito dell'hub delle immagini è gcr.io/apigee-release/hybrid/
.
Le immagini che utilizzano DIGEST devono essere impostate singolarmente in ogni sottocomponente.
Apigee crea il percorso dell'immagine finale combinando il valore di quanto segue:
- "Image Hub", che può essere sostituito in apigee-hybrid-config.yaml (consulta la sezione Utilizzo di immagini Docker da repository privati per i passaggi dettagliati su come sostituire Image Hub).
- Il valore di
IMAGE_TAG
viene ottenuto dal campoversion
, presente all'interno del file YAML per ciascuno dei singoli componenti (ad esempio, apigee-organization.yaml). Apigee tagga le immagini con la versione di Apigee Hybrid, il che significa cheIMAGE_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 containerapigee-runtime
,IMAGE_NAME
sarà apigee-runtime.
Pertanto, un esempio completo di percorso dell'immagine sarebbe gcr.io/apigee-release/hybrid/apigee-runtime:1.8.0
In questo modo, viene costruito il percorso dell'immagine finale, che verrà poi utilizzato all'interno di ciascun container nei rispettivi pod.
Service account Google Cloud
I service account Google Cloud sono account utilizzati dalle applicazioni per effettuare chiamate autorizzate alle API di Google. È possibile scaricare le chiavi del account di servizio Google Cloud, che possono poi essere utilizzate per l'autenticazione. Apigee prevede che l'utente fornisca le chiavi del account di servizio creando secret. Di seguito sono riportati i nomi dei componenti e il nome predefinito del secret in cui cerca le chiavi del account di servizio:
Componente | Sottocomponente | Nome secret Kubernetes predefinito contenente la chiave del account di servizio |
---|---|---|
organizzazione | ||
connectAgent | apigee-connect-agent-gcp-sa-key-${ORG_NAME} |
|
watcher | apigee-watcher-gcp-sa-key-${ORG_NAME} |
|
mart | apigee-mart-gcp-sa-key-${ORG_NAME} |
|
udca | apigee-udca-gcp-sa-key-${ORG_NAME} |
|
ingressGateways | N/D | |
environment | ||
runtime | apigee-runtime-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
udca | apigee-udca-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
sincronizzatore | apigee-synchronizer-gcp-sa-key-${ORG_NAME}-${ENV_NAME} |
|
telemetry | ||
metriche | apigee-metrics-gcp-sa-key |
|
containerLogs | apigee-logger-gcp-sa-key |
Service account Kubernetes
Gli account di servizio Kubernetes forniscono identità ai pod nel cluster. Per impostazione predefinita, il controller Apigee li crea automaticamente. Tuttavia, se vuoi ignorare la creazione (ad esempio, quando utilizzi le Workload Identity), puoi farlo specificando il campo podServiceAccountName
nei vari sottocomponenti.
Elenco dei componenti e dei rispettivi sottocomponenti in cui è possibile specificare il account di servizio Kubernetes insieme al nome predefinito del account di servizio Kubernetes quando abiliti la patch di identità del workload.
Componente | Sottocomponente | Nome predefinito (disponibile quando hai abilitato la patch di Workload Identity) |
---|---|---|
organizzazione | ||
connectAgent | apigee-connect-agent-svc-account-${ORG_NAME} |
|
watcher | apigee-watcher-svc-account-${ORG_NAME} |
|
mart | apigee-mart-svc-account-${ORG_NAME} |
|
udca | apigee-udca-svc-account-${ORG_NAME} |
|
environment | ||
sincronizzatore | apigee-synchronizer-svc-account-${ORG_NAME}-${ENV_NAME} |
|
udca | apigee-udca-svc-account-${ORG_NAME}-${ENV_NAME} |
|
runtime | apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME} |
|
datastore | ||
cassandra | apigee-datastore-svc-account |
|
telemetry | ||
metricsApp | apigee-metricsApp-svc-account |
|
metricsProxy | apigee-metricsProxy-svc-account |
|
metricsAdapter | apigee-metricsAdapter-svc-account |
|
containerLogs | apigee-container-logs-svc-account |
Identità del workload
Le identità dei workload consentono ai pod (che utilizzano i service account Kubernetes) in esecuzione in GKE di autenticarsi direttamente con le API Google Cloud senza richiedere le chiavi del account di servizio Google Cloud.
Aggiungere un nuovo ambiente
.
├── ...
├── instances/instance1/components
│ ├── ...
│ ├── environments
│ │ ├── dev
│ │ │ └── apigee-environment.yaml
│ │ │ └── secrets.yaml
│ │ └── new-env-name (new)
│ │ └── apigee-environment.yaml (new)
│ │ └── secrets.yaml (new)
└── ...
Aggiungere un nuovo ambiente è semplice:
- Creare una nuova cartella all'interno della directory degli ambienti (o in base alla struttura delle cartelle)
- Copia il file
apigee-environment.yaml
da qualsiasi ambiente esistente nella nuova cartella. - Se vuoi creare nuove chiavi di crittografia e un nuovo account di servizio per il nuovo ambiente, copia
secrets.yaml
nella nuova cartella e rinomina i secret in modo appropriato per distinguerli dagli altri ambienti esistenti (in genere, aggiungendo il nome dell'ambiente come suffisso). - Apportare le modifiche appropriate a
apigee-environment.yaml
, ad esempio:- Modificare il nome dell'ambiente
- Se verranno creati nuovi service account e chiavi di crittografia, questi dovranno essere referenziati correttamente nel file YAML.
- Applicazione dei
yaml
:
kubectl apply -f components/environments/new-env-name/secrets.yaml
kubectl apply -f components/environments/new-env-name/apigee-environment.yaml
Utilizzo dell'eliminazione forzata in Apigee Datastore
Se l'eliminazione del datastore non procede per qualsiasi motivo, ora il datastore Apigee può essere eliminato forzatamente utilizzando i seguenti comandi, indipendentemente dallo stato attuale del cluster.
Elimina
apigeeds
nello spazio dei nomiapigee
:Kubectl delete -n apigee apigeeds default
Se questo passaggio si blocca, puoi uscire utilizzando Ctrl + C.
Modifica un nuovo
apigeeds
:Kubectl edit -n apigee apigeeds default
Aggiungi/aggiorna il campo forceDelete nella specifica del datastore Apigee
spec: forceDelete: true
Salva il file ed esci.
Ora attendi l'eliminazione del datastore. L'eliminazione di tutte le risorse Cassandra può richiedere alcuni minuti.
Comprendere lo script
Lo script apigee-hybrid-setup.sh
esegue alcune convalide di base e aiuta ad automatizzare i passaggi che altrimenti dovresti eseguire se vuoi una personalizzazione più dettagliata, come descritto in Installazione personalizzata di Apigee Hybrid. Anche con l'installazione personalizzata, puoi comunque utilizzare parzialmente lo script per aiutarti con determinate attività.
Puoi eseguire ./tools/apigee-hybrid-setup.sh --help
per visualizzare un elenco dei flag supportati e ricevere ulteriore aiuto con lo script. Al momento sono supportati i seguenti flag:
--namespace
Per impostazione predefinita, lo script installa tutti i componenti nello spazio dei nomiapigee
. 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 ingcloud
--envgroup
Utilizzato per fornire il nome del gruppo di ambienti all'interno della tua organizzazione. Se non specificato, viene eseguito un tentativo di query delle API del control plane per determinare il nome del gruppo di ambienti. Se vengono trovati più gruppi di ambienti, viene restituito un errore e lo script viene chiuso.--env
Utilizzato per fornire il nome dell'ambiente all'interno della tua organizzazione. Se non specificato, viene effettuato un tentativo di eseguire query sulle API del control plane per determinare il nome dell'ambiente. Se vengono trovati più ambienti o l'ambiente non fa parte del gruppo di ambienti, viene restituito un errore e lo script viene chiuso.--cluster-name
Il nome del cluster Kubernetes.--cluster-region
La regione in cui si trova il cluster Kubernetes--gcp-project-id
L'ID progetto Google Cloud in cui esiste il cluster Kubernetes--ingress-domain
Specifica il nome host/nome di dominio che verrà utilizzato per generare i certificati TLS autofirmati per istio ingress-gateway. Se non viene specificato alcun valore, viene eseguito un tentativo di determinare il valore eseguendo query sulle API del control plane per ottenere il valore da envgroup. Se si sono verificati problemi con la determinazione di envgroup o se sono stati configurati più nomi host per envgroup, viene restituito un errore e lo script viene chiuso.--generate-internal-tls-certs
Verrà creato un secret di Kubernetes denominato apigee-ca che contiene una coppia di certificato e chiave generata da noi.--create-ingress-tls-certs
Verrà generato un secret denominato{ORG_NAME}-{ENV_GROUP_NAME}
(derivato dal nome dell'organizzazione e del gruppo di ambienti) all'interno dello spazio dei nomi istio-system che conterrà una coppia di certificato e chiave da utilizzare per la comunicazione TLS. Il nome di dominio utilizzato per generare questi certificati deriva dal valore trovato nella configurazione di envgroup. In caso di conflitti (ad esempio quando troviamo più domini), verranno visualizzati i messaggi di errore appropriati.--create-gcp-sa-and-secrets
Crea un singolo account di servizio Google Cloud nel progetto Google Cloud, scarica le chiavi e poi crea i secret Kubernetes contenenti la chiave. I nomi dei secret sono disponibili in Service account Google Cloud.--fill-values
Sostituisce i valori di org, env, envgroup e altri nomi ovunque siano richiesti nei vari file YAML.--apply-configuration
Verranno creati gli emittenti di certificati, le definizioni di risorse personalizzate, i webhook, i ruoli e la risorsa controller. Le risorse verranno create nell'ordine corretto e il comando verrà bloccato finché tutte non saranno integre.-- rename-directories
Rinomina l'ambiente e il gruppo di ambienti con i nomi dell'ambiente e del gruppo di ambienti corretti.--verbose
Mostra l'output dettagliato per il debug.--help
Visualizza le informazioni sull'utilizzo.--setup-all
Verranno eseguite tutte le attività che possono essere eseguite da questo script
Struttura delle cartelle di configurazione di Apigee Hybrid
Per impostazione predefinita, la cartella apigee-hybrid-setup
ha la seguente struttura gerarchica:
.
├── bases
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-controller-deployment.yaml
│ │ │ └── kustomization.yaml
│ │ └── apigee-ingressgateway-manager
│ │ ├── apigee-ingressgateway-manager-deployment.yaml
│ │ └── kustomization.yaml
│ ├── datastore
│ │ └── backup-and-restore
│ │ ├── backup
│ │ │ ├── cronjob.yaml
│ │ │ └── kustomization.yaml
│ │ ├── common
│ │ │ ├── kustomization.yaml
│ │ │ ├── rbac.yaml
│ │ │ └── tls-certificate.yaml
│ │ └── restore
│ │ ├── job.yaml
│ │ └── kustomization.yaml
│ └── initialization
│ ├── certificates
│ │ ├── certificates-and-issuers.yaml
│ │ └── kustomization.yaml
│ ├── crds
│ │ ├── customresourcedefinition-apigeedatastores.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeedeployments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeenvironments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeredis.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeerouteconfigs.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeroutes.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeetelemetries.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-cassandradatareplications.apigee.cloud.google.com.yaml
│ │ └── kustomization.yaml
│ ├── openshift
│ │ ├── kustomization.yaml
│ │ └── scc.yaml
│ ├── rbac
│ │ ├── apigee-controller
│ │ │ ├── kustomization.yaml
│ │ │ └── rbac.yaml
│ │ └── apigee-embedded-ingress-controller
│ │ ├── cluster-role-bindings.yaml
│ │ ├── cluster-roles.yaml
│ │ ├── kustomization.yaml
│ │ └── service-account.yaml
│ └── webhooks
│ ├── kustomization.yaml
│ ├── mutatingwebhookconfiguration.yaml
│ └── validatingwebhookconfiguration.yaml
├── CONTRIBUTING.md
├── docs
│ └── api_references
│ ├── v1alpha1.md
│ └── v1alpha2.md
├── kokoro
│ ├── build.sh
│ ├── common.cfg
│ ├── continuous.cfg
│ ├── presubmit.cfg
│ └── release.cfg
├── LICENSE
├── overlays
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-hybrid-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ ├── apigee-ingressgateway-manager
│ │ │ ├── apigee-ingressgateway-manager-deployment-patch.yaml
│ │ │ ├── apigee-istio-mesh-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ ├── initialization
│ │ ├── certificates
│ │ │ ├── apigee-ingressgateway-manager-certificate-patch.yaml
│ │ │ ├── apigee-serving-cert-patch.yaml
│ │ │ ├── components
│ │ │ │ └── disable-apigee-root-certificate-generation
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ ├── crds
│ │ │ └── kustomization.yaml
│ │ ├── ingress
│ │ │ ├── envoyfilter-1.11.yaml
│ │ │ └── kustomization.yaml
│ │ ├── namespace.yaml
│ │ ├── openshift
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── rbac
│ │ │ ├── apigee-controller
│ │ │ │ └── kustomization.yaml
│ │ │ ├── apigee-ingressgateway-manager
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ └── webhooks
│ │ ├── kustomization.yaml
│ │ ├── mutatingwebhookconfiguration.yaml
│ │ └── validatingwebhookconfiguration.yaml
│ └── instances
│ └── instance1
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── gcs-backup
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── cron-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── gcs-restore
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── job-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── multi-region
│ │ │ │ ├── cassandra-data-replication.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── non-gcs-backup
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── cron-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── non-gcs-restore
│ │ │ │ ├── apigee-datastore-patch.yaml
│ │ │ │ ├── job-patch.yaml
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── tls-certificate-patch.yaml
│ │ │ ├── openshift-scc
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── scc.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-envgroup
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── openshift-scc
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── kustomization.yaml
│ │ │ ├── patch.yaml
│ │ │ └── service-accounts.yaml
│ │ └── workload-identity-metrics
│ │ ├── kustomization.yaml
│ │ ├── patch.yaml
│ │ └── service-accounts.yaml
│ └── kustomization.yaml
├── README.md
├── templates
│ ├── certificate-org-envgroup.yaml
│ ├── secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml
│ ├── secret-apigee-cassandra-backup-and-restore-key-file.yaml
│ ├── secret-gcp-sa-key.yaml
│ └── secret-ingress-tls-cert-key.yaml
└── tools
├── apigee-hybrid-setup.sh
├── apigee-pull-push.sh
├── common.sh
├── create-service-account.sh
└── dump_kubernetes.sh
Una versione dei file precedenti è disponibile nel tag preview-1 del repository GitHub all'indirizzo https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1.
La cartella precedente contiene i manifest Kubernetes per il runtime di Apigee Hybrid e utilizza Kustomize per la gestione della configurazione. I manifest sono organizzati in base al concetto di basi e overlay di Kustomize. La cartella bases contiene la configurazione minima richiesta per ogni componente Apigee. La cartella degli overlay contiene più funzionalità(configurazioni) aggiuntive definite come componenti. Un componente può essere decommentando il riferimento al componente nel file kustomization.yaml
Esempio :per abilitare gcs-backup
per l'archivio dati Apigee, il componente gcs-backup
è stato decommentato nel file customization.yaml riportato di seguito.
Percorso : ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/kustomization.yaml
namespace: "apigee" # kpt-set: ${APIGEE_NAMESPACE}
resources:
- apigee-datastore.yaml
components:
# - ./components/http-proxy
# - ./components/nodeselector/
# - ./components/imagepullsecret
# - ./components/workload-identity
# - ./components/openshift-scc
- ./components/gcs-backup (uncommented)
# - ./components/gcs-restore
# - ./components/non-gcs-backup
# - ./components/non-gcs-restore
Qualsiasi valore che richiede personalizzazioni deve essere impostato nel file patch.yaml corrispondente per gcs-backup.
Nel file riportato di seguito, il valore di CLOUD_STORAGE_BUCKET_PATH
deve essere impostato dall'utente
Percorso: $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/datastore/components/gcs-backup/cron-patch.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: apigee-cassandra-backup
namespace: apigee
spec:
schedule: "${YOUR_BACKUP_SCHEDULE_CODE}" # To be modified
jobTemplate:
spec:
template:
spec:
containers:
- name: apigee-cassandra-backup
env:
- name: APIGEE_CLOUDPROVIDER
value: "GCP"
- name: DATABASE_STORAGE_BUCKET
value: "${CLOUD_STORAGE_BUCKET_PATH}" # To be modified. REQUIRED
volumeMounts:
- name: apigee-cassandra-backup
mountPath: /var/secrets/google
volumes:
- name: apigee-cassandra-backup
secret:
secretName: "apigee-cassandra-backup-and-restore-svc-account"
Allo stesso modo, qualsiasi funzionalità/configurazione che richiede personalizzazioni può essere abilitata rimuovendo il commento dal componente in kustomization.yaml del componente Apigee. Inoltre, se necessario, i valori corrispondenti per i campi in patch.yaml del componente devono essere impostati di conseguenza.
Breve spiegazione delle cartelle e dei file:
basi
Questa cartella contiene i modelli con la configurazione minima richiesta da ciascuno dei componenti Apigee. Non sarebbe necessario apportare modifiche ai manifest in questa cartella.
overlay
Questa cartella contiene i modelli dei componenti di Kustomize per le configurazioni aggiuntive
inizializzazione
namespaces.yaml
Lo spazio dei nomi in cui verranno installati i componenti del data plane di Apigee. Il nome dello spazio dei nomi predefinito è apigee
certificati
Contiene le risorse Issuer
e Certificate
utilizzate per emettere certificati per i webhook. Contiene anche Issuer
utilizzato per emettere certificati per vari pod per la comunicazione TLS.
rbac
Contiene Role
, ClusterRole
, RoleBinding
e ClusterRoleBinding
che verranno utilizzati da vari componenti.
crds
Contains the definition of all the CRDs which are used by Apigee.
webhook
Contiene ValidatingWebhookConfiguration
eMutatingWebhookConfiguration
che verranno utilizzati per eseguire le convalide sulle risorse personalizzate.
In entrata
Contiene la configurazione applicabile a tutti i pod Ingress. Es. Modifica dell'intestazione comune, controllo di integrità e così via.
openshift
Contiene la definizione di SecurityContextConstraints di OpenShift.
Controller
apigee-controller
apigee-hybrid-config.yaml
Contiene un ConfigMap
fornito come input in apigee-controller-manager.yaml. Questo oggetto ConfigMap contiene configurazioni come imageHub
, imagePullSecrets
, forwardProxy
, tra le altre.
apigee-controller-deployment.yaml
Contiene due servizi per il controller e il webhook e il deployment per il controller. Se vuoi utilizzare un'immagine privata per il controller, è qui che dovrai apportare la modifica.
istiod
Apigee-istio-mesh-config.yaml Contiene la configurazione del mesh per Istio utilizzata da Apigee. Ciò non è applicabile ad altre installazioni di ASM/Istio nel cluster.
apigee-ingressgateway-manager-deployment-patch.yaml
Contiene un servizio e un deployment di Istiod. Si tratta di un istiod privato utilizzato solo per i casi d'uso di Apigee.
instances/{instanceName}
datastore
apigee-datastore.yaml
Contiene la risorsa personalizzata ApigeeDatastore
che gestisce Cassandra.
secrets.yaml
Contiene le credenziali predefinite per il datastore.
redis
apigee-redis.yaml
Contiene la risorsa personalizzata ApigeeRedis
che gestisce Redis.
secrets.yaml
Contiene le credenziali predefinite per il datastore.
organizzazione
apigee-organization.yaml
Contiene la risorsa personalizzata ApigeeOrganization
che gestisce altri sottocomponenti come connectAgent, watcherAndSynchronizer, MART,UDCA e Ingress.
secrets.yaml
Contiene i Secret
s a cui viene fatto riferimento in apigee-organization.yaml. Alcuni segreti sono commentati perché vengono generati dallo script. Se disattivi la generazione, dovrai creare manualmente
environments
Contiene tutti gli ambienti della tua organizzazione. Devi creare una cartella separata per ogni ambiente copiando quella già fornita e configurandola in base ai requisiti.
dev
apigee-environment.yaml
Contiene la risorsa personalizzata ApigeeEnvironment
che gestisce altri sottocomponenti come il runtime.
secrets.yaml
Contiene i Secret
s a cui viene fatto riferimento in apigee-environment.yaml. Alcuni segreti sono commentati perché vengono generati dallo script. Se disattivi
la loro generazione, dovrai crearli manualmente
telemetria
apigee-telemetry.yaml
Contiene la risorsa personalizzata ApigeeTelemetry
.
secrets.yaml
Contiene i Secret
a cui viene fatto riferimento in apigee-telemetry.yaml. Alcuni segreti sono commentati perché vengono generati dallo script. Se disattivi la generazione, dovrai creare manualmente
route-config
dev-envgroup
apigee-route-config.yaml
Contiene la risorsa personalizzata ApigeeRouteConfig
.
secrets.yaml
Contiene un Secret
a cui viene fatto riferimento in apigee-route-config.yaml. È commentato perché viene generato automaticamente dallo script apigee-hybrid-setup.sh e viene mantenuto lì per fornire un esempio di come dovrebbe apparire il secret se lo creassi manualmente.
diagnostico
diagnostic-collector.yaml
Risorse che verranno utilizzate per l'attivazione del deployment della diagnostica
strumenti
apigee-hybrid-setup.sh
apigee-create-service-account.sh
dump-kubernetes.sh
apigee-pull-push.sh
Archiviazione delle chiavi del account di servizio in vault esterni
Vault (di Hashicorp) è un sistema di gestione dei secret molto diffuso che presenta diverse integrazioni con gli archivi dei secret forniti da Google, Azure, AWS e altri. Hashicorp Vault consente di recuperare i secret da una fonte esterna e utilizzarli all'interno delle risorse Kubernetes. Esistono diversi modi per utilizzare Vault per recuperare i secret. I seguenti passaggi fungono da esempio di base su come utilizzare il provider CSI Vault per montare le chiavi del account di servizio Google Cloud archiviate in un motore di secret fornito da Vault.
- Utilizzeremo Helm per installare le risorse correlate a Vault nel cluster. Segui i passaggi descritti in Installazione di Helm per configurare Helm nel tuo sistema.
Segui i passaggi descritti in Installare il grafico Helm di Vault, ovvero:
Aggiunta del repository Hashicorp a Helm
helm repo add hashicorp https://helm.releases.hashicorp.com
Aggiorna i repository Helm
helm repo update
Installazione di Vault
helm install vault hashicorp/vault \ --set "server.dev.enabled=true" \ --set "injector.enabled=false" \ --set "csi.enabled=true"
Ora memorizziamo il segreto in Vault.
Recupera una shell all'interno del pod di sviluppo di Vault
kubectl exec -it vault-0 -- /bin/sh ```
In questo esempio utilizzeremo il motore dei secret chiave/valore per archiviare i dati.
vault kv put secret/runtime-gcp-sa-key key="${BASE_64_ENCODED_KEY}"
Per verificare che la chiave sia stata archiviata correttamente, utilizza:
vault kv get secret/runtime-gcp-sa-key
Configura l'autenticazione per consentire al pod di runtime di estrarre la chiave. Come descritto in Account di servizio Kubernetes, gli account di servizio Kubernetes forniscono un'identità ai pod e consentono loro di autenticarsi con altri sistemi.
Recupera una shell all'interno del pod di sviluppo di Vault
kubectl exec -it vault-0 -- /bin/sh
Abilita il metodo di autenticazione Kubernetes
vault auth enable kubernetes
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
Crea il criterio di autenticazione
vault policy write apigee-runtime-app - <<EOF path "secret/data/runtime-gcp-sa-key" { capabilities = ["read"] } EOF
Associa la policy al account di servizio
vault write auth/kubernetes/role/apigee-runtime-role \ bound_service_account_names=apigee-runtime-sa \ bound_service_account_namespaces=${APIGEE_NAMESPACE} \ policies=apigee-runtime-app \ ttl=20m
In questo caso, supponiamo che l'account di servizio si trovi nello spazio dei nomi apigee. Se hai un altro spazio dei nomi per l'installazione di Apigee, utilizzerai questo nome.
Esci dalla shell all'interno di vault-0
exit
Installa il driver CSI Secrets Store
# Add repo to helm helm repo add secrets-store-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/secrets-store-csi-driver/master/charts # Install driver in cluster helm install csi secrets-store-csi-driver/secrets-store-csi-driver
Crea una risorsa Kubernetes
SecretProviderClass
che fa riferimento al secret che hai creato all'interno del vaultcat > 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
Applica
yaml
kubectl apply -f spc-vault.yaml
Crea il account di servizio Kubernetes a cui abbiamo assegnato le autorizzazioni nel passaggio (4.e)
kubectl create serviceaccount -n ${APIGEE_NAMESPACE} apigee-runtime-sa
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"
Applica le modifiche:
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/$ENV_NAME
Upgrade di Apigee hybrid
Devi aver completato tutti i requisiti menzionati in Prerequisiti. Inoltre, ti consigliamo di eseguire un riavvio sequenziale di tutti i componenti per verificare l'integrità del cluster. L'ordine di riavvio sarà Cassandra, Redis, ApigeeOrganization e ApigeeEnvironment.
Crea backup
Crea una copia di backup della configurazione ibrida attuale. Il backup sarà necessario nel caso in cui tu debba eseguire il rollback dell'upgrade alla versione attuale.
tar -czvf apigee-hybrid-install.v-X.Y.Z.tar.gz $HYBRID_INSTALL_BASE_DIR
Crea il backup del database Cassandra. I backup di Cassandra sono un'importante misura di protezione contro scenari di emergenza.
Esegui l'upgrade della piattaforma Kubernetes, se necessario
Questo passaggio non è obbligatorio ogni volta, ma dovrai eseguire l'upgrade della piattaforma Kubernetes come Kubernetes, Openshift e dei componenti come cert-manager, Cassandra e così via se non sono più supportati dalla versione più recente di Apigee Hybrid. La documentazione conterrà le versioni supportate di piattaforme e componenti.
Scaricare i file di configurazione
Scarica il repository e sostituisci le cartelle bases
e tools
nella configurazione ibrida di Apigee esistente con una più recente:
Clona il tag preview-1 del repository GitHub all'indirizzo
https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1
Il repository clonato avrà una struttura simile a quella descritta in Struttura delle cartelle di configurazione di Apigee Hybrid:
sostituisci l'inizializzazione, gli strumenti e la cartella del controller nella configurazione ibrida Apigee esistente.
export HYBRID_INSTALL_HOME=PATH_TO_PREVIOUS_HYBRID_INSTALL_DIRECTORY mv -f bases $HYBRID_INSTALL_HOME/bases mv -f tools $HYBRID_INSTALL_HOME/tools
Aggiorna le autorizzazioni del account di servizio, se necessario
Anche questo passaggio non è obbligatorio ogni volta, ma dovrai creare un nuovo account di servizio o aggiornare le autorizzazioni dei service account esistenti, se necessario. La guida all'upgrade fornisce i dettagli sui service account da modificare o creare e sui ruoli da aggiungere.
Se devi modificare le autorizzazioni dei service account esistenti, utilizza il comando
gcloud
appropriato. La guida all'upgrade conterrà i comandi e i ruoli dettagliati da aggiungere.gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:apigee-component@$PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/$NEW_ROLE"
Se la versione più recente di Apigee Hybrid potrebbe richiedere un account di servizio aggiuntivo per i componenti nuovi / esistenti, devi crearli. Puoi utilizzare lo script
apigee-create-service-account.sh
fornito nella cartella degli strumenti per creare nuovi service account. Poiché lo script verrà già aggiornato nell'ambito del passaggio 4, conterrà i dettagli e un nuovo profilo necessari per un nuovo account di servizio da creare.Il nome del account di servizio appena creato deve essere referenziato nel CR del componente corrispondente.
./tools/create-service-account --env prod --profile apigee-component
Esegui l'upgrade del controller
Modifica i campi della versione per i componenti elencati in ${INSTALL_DIR}/overlays/instances/$INSTANCE_DIR/kustomization.yaml
con la versione ibrida pertinente.
Ecco un esempio di file $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/kustomization.yaml. Il valore del campo della versione deve essere aggiornato alla versione pertinente
resources:
- datastore/
- environments/
- organization/
- redis/
- route-config/
- telemetry/
patches:
- target:
group: apigee.cloud.google.com
version: v1alpha1
kind: ApigeeDatastore
patch: |-
- op: add
path: /spec/version
value: 1-6-1 (Modify the version)
- target:
group: apigee.cloud.google.com
version: v1alpha2
kind: ApigeeEnvironment
patch: |-
- op: add
path: /spec/version
value: 1-6-1 (Modify the version)
Segui la stessa serie di passaggi fornita in Crea risorse di inizializzazione e controller nel flusso di lavoro di installazione di Apigee hybrid. Puoi utilizzare lo script o seguire i passaggi manuali forniti per eseguire l'upgrade delle risorse di inizializzazione e del controller.
Aggiorna i componenti Kubernetes di Apigee
Dovrai apportare le seguenti modifiche: - In caso di modifiche all'architettura o introduzione di nuovi campi o ritiro di campi precedenti, dovrai modificare le CR con le modifiche appropriate in base alle istruzioni fornite nella guida all'upgrade. - Come minimo, devi aggiornare i campi della versione all'interno delle CR (che indicheranno la versione di Apigee hybrid installata) alla versione più recente di Apigee hybrid.
Applica le modifiche per i CR di Apigee. Per l'ambiente non di produzione, puoi applicare tutte le modifiche ai componenti Apigee contemporaneamente
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
Rollback di Apigee Hybrid
Ripristina apigee-hybrid-setup
Spostati nella directory che contiene la versione precedente della configurazione di Apigee hybrid. Se non è disponibile, ripristinalo dal file zip creato nel passaggio 1 [link] durante l'upgrade di Apigee Hybrid.
Eseguire il rollback dei componenti di Kubernetes
Applica le modifiche per i CR apigee
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}
Controller di rollback
Segui la stessa serie di passaggi forniti per creare risorse di inizializzazione e controller nel flusso di lavoro di installazione di Apigee hybrid. Puoi utilizzare uno script o seguire i passaggi manuali forniti per eseguire il rollback delle risorse di inizializzazione e del controller.
Esegui la pulizia
Dovrai eseguire la pulizia di eventuali nuove risorse aggiuntive create durante l'upgrade, come nuovi componenti o service account introdotti nella versione più recente di ibrido. Nella guida all'upgrade verranno fornite tutte le risorse da pulire e i passaggi per farlo.
Eliminazione di un ambiente
Di seguito sono riportati i passaggi per eliminare tutte le risorse correlate a un ambiente dal cluster Kubernetes:
Recupera il nome della CR dell'ambiente. Per farlo, recupera tutti gli ambienti:
kubectl get env -n ${APIGEE_NAMESPACE}
Memorizza il nome della risorsa nella variabile di ambiente
APIGEE_ENV
.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
Elimina i secret del account di servizio Google Cloud:
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}')
Elimina i service account Kubernetes:
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')
Elimina la risorsa personalizzata dell'ambiente Apigee:
kubectl -n ${APIGEE_NAMESPACE} delete env $APIGEE_ENV
Eliminazione di una configurazione ibrida
Di seguito sono riportati i passaggi per eliminare tutte le risorse correlate ad Apigee Hybrid dal cluster Kubernetes:
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')
Dovrai eliminare i componenti del piano dati ibrido di Apigee di cui è stato eseguito il deployment. Utilizza questo comando per eliminare tutti i componenti:
kubectl delete -k ${INSTALL_DIR}/overlays/instances/$INSTANCE_NAME
Questo passaggio è necessario solo se non hai utilizzato il nome predefinito per i secret account di servizio Kubernetes, i secret account di servizio Google Cloud e così via. Se hai utilizzato i nomi predefiniti, questi verranno eliminati nel passaggio successivo. In caso contrario, dovrai eliminarli manualmente utilizzando i seguenti comandi:
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get ${APIGEE_COMPONENT} ${APIGEE_COMPONENT_NAME} -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}') kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get ${APIGEE_COMPONENT} ${APIGEE_COMPONENT_NAME} -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')
Nel caso di OpenShift, devi eliminare scc (Security Context Constraints) creato durante l'installazione di Apigee hybrid.
kubectl delete scc ${SECURITY_CONTEXT_CONSTRAINTS_NAME}
Esegui il comando riportato di seguito per eliminare ruoli, rolebinding, CRD, deployment del controller e così via.
kubectl delete -k ${INSTALL_DIR}/overlays/initialization/ingress kubectl delete -k ${INSTALL_DIR}/overlays/initialization/rbac kubectl delete -k ${INSTALL_DIR}/overlays/initialization/webhooks kubectl delete -k ${INSTALL_DIR}/overlays/initialization/crds kubectl delete -k ${INSTALL_DIR}/overlays/initialization/certificates
Esegui il comando riportato di seguito per eliminare lo spazio dei nomi apigee
kubectl delete -f ${INSTALL_DIR}/overlays/initialization/namespace.yaml
In alternativa, utilizza il comando:
kubectl delete $APIGEE_NAMESPACE
Installazione multi-istanza
La configurazione multi-istanza si riferisce alla configurazione ibrida che può estendersi su più regioni o anche all'interno delle stesse regioni. Apigee consiglia di organizzare le configurazioni della seconda istanza in una struttura di directory separata,poiché le configurazioni dell'ambiente (repliche e così via) sono invariabilmente diverse tra le istanze. Le configurazioni di ogni istanza sono disaccoppiate e organizzate in modo indipendente nelle rispettive strutture di cartelle.
Ad esempio, per una configurazione Active-Passive in uno scenario multiregionale, potresti voler configurare una seconda regione in warm standby con dimensioni e configurazioni diverse.
Nella struttura delle cartelle riportata di seguito, puoi creare una copia della directory instance1 denominata instance2 e modificare le configurazioni di datastore e ingresso in base alle esigenze.
Struttura delle cartelle apigee-hybrid-setup
per la configurazione di più istanze.
.
├── bases
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-controller-deployment.yaml
│ │ │ └── kustomization.yaml
│ │ └── istiod
│ │ ├── apigee-ingressgateway-manager-deployment.yaml
│ │ └── kustomization.yaml
│ └── initialization
│ ├── certificates
│ │ ├── certificates-and-issuers.yaml
│ │ └── kustomization.yaml
│ ├── crds
│ │ ├── customresourcedefinition-apigeedatastores.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeedeployments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeenvironments.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeredis.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeerouteconfigs.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeeroutes.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-apigeetelemetries.apigee.cloud.google.com.yaml
│ │ ├── customresourcedefinition-cassandradatareplications.apigee.cloud.google.com.yaml
│ │ └── kustomization.yaml
│ ├── ingress
│ │ ├── envoyfilter-1.11.yaml
│ │ └── kustomization.yaml
│ ├── openshift
│ │ ├── kustomization.yaml
│ │ └── scc.yaml
│ ├── rbac
│ │ ├── apigee-controller
│ │ │ ├── kustomization.yaml
│ │ │ └── rbac.yaml
│ │ └── apigee-embedded-ingress-controller
│ │ ├── cluster-role-bindings.yaml
│ │ ├── cluster-roles.yaml
│ │ ├── kustomization.yaml
│ │ └── service-account.yaml
│ └── webhooks
│ ├── kustomization.yaml
│ ├── mutatingwebhookconfiguration.yaml
│ └── validatingwebhookconfiguration.yaml
├── instances
│ └── instance1 (Add the 2nd instance under instances directory similar to instance1)
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-env-group
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ └── workload-identity-metrics
│ │ ├── apigee-workload-identities.yaml
│ │ ├── kustomization.yaml
│ │ └── patch.yaml
│ └── kustomization.yaml
├── overlays
│ ├── controllers
│ │ ├── apigee-controller
│ │ │ ├── apigee-hybrid-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ ├── istiod
│ │ │ ├── apigee-ingressgateway-manager-deployment-patch.yaml
│ │ │ ├── apigee-istio-mesh-config.yaml
│ │ │ ├── components
│ │ │ │ ├── imagepullsecret
│ │ │ │ │ ├── kustomization.yaml
│ │ │ │ │ └── patch.yaml
│ │ │ │ └── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ ├── initialization
│ │ ├── certificates
│ │ │ ├── apigee-ingressgateway-manager-certificate.yaml
│ │ │ └── kustomization.yaml
│ │ ├── crds
│ │ │ └── kustomization.yaml
│ │ ├── ingress
│ │ │ └── kustomization.yaml
│ │ ├── namespace.yaml
│ │ ├── openshift
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── rbac
│ │ │ ├── apigee-controller
│ │ │ │ └── kustomization.yaml
│ │ │ ├── apigee-embedded-ingress-controller
│ │ │ │ └── kustomization.yaml
│ │ │ └── kustomization.yaml
│ │ └── webhooks
│ │ ├── kustomization.yaml
│ │ ├── mutatingwebhookconfiguration.yaml
│ │ └── validatingwebhookconfiguration.yaml
│ └── instances
│ └── instance1
│ ├── datastore
│ │ ├── apigee-datastore.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── openshift-scc
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── scc.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── environments
│ │ ├── kustomization.yaml
│ │ └── test
│ │ ├── apigee-environment.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── kustomization.yaml
│ ├── organization
│ │ ├── apigee-organization.yaml
│ │ ├── components
│ │ │ ├── http-proxy
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── redis
│ │ ├── apigee-redis.yaml
│ │ ├── components
│ │ │ ├── imagepullsecret
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ ├── nodeselector
│ │ │ │ ├── kustomization.yaml
│ │ │ │ └── patch.yaml
│ │ │ └── workload-identity
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── kustomization.yaml
│ │ └── secrets.yaml
│ ├── route-config
│ │ ├── kustomization.yaml
│ │ └── test-envgroup
│ │ ├── apigee-route-config.yaml
│ │ ├── components
│ │ │ ├── http-and-non-sni-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ ├── http-client
│ │ │ │ ├── apigee-route.yaml
│ │ │ │ └── kustomization.yaml
│ │ │ └── non-sni-client
│ │ │ ├── apigee-route.yaml
│ │ │ └── kustomization.yaml
│ │ └── kustomization.yaml
│ └── telemetry
│ ├── apigee-telemetry.yaml
│ ├── components
│ │ ├── http-proxy
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── imagepullsecret
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── logger
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── metrics
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── nodeselector
│ │ │ ├── kustomization.yaml
│ │ │ └── patch.yaml
│ │ ├── openshift-scc
│ │ │ ├── kustomization.yaml
│ │ │ └── scc.yaml
│ │ ├── workload-identity-logger
│ │ │ ├── apigee-workload-identities.yaml
│ │ │ └── kustomization.yaml
│ │ └── workload-identity-metrics
│ │ ├── apigee-workload-identities.yaml
│ │ ├── kustomization.yaml
│ │ └── patch.yaml
│ └── kustomization.yaml
├── README.md
├── templates
│ ├── ingress-certificate.yaml
│ ├── ingress-cert-secret.yaml
│ └── service-account-key-secret.yaml
└── tools
├── apigee-hybrid-setup.sh
├── common.sh
├── create-service-account.sh
└── dump_kubernetes.sh
Configurazione di più istanze su GKE
Prerequisiti
Prima di configurare più istanze di ibrido, devi aver completato i seguenti prerequisiti:
- Configura cluster Kubernetes in più regioni(uguali o diverse) con blocchi CIDR diversi
- Configurare la comunicazione tra regioni
- Apri le porte 7000 e 7001 di Cassandra tra i cluster Kubernetes in tutte le regioni (la porta 7000 può essere utilizzata come opzione di backup durante la risoluzione dei problemi). Vedi anche Configurare le porte.
Puoi utilizzare uno strumento come ntpdate per verificare che gli orari del server siano sincronizzati.
Configura l'host seed multiregionale
- Crea una copia della cartella $INSTANCE_NAME dall'istanza esistente e aggiungila alla cartella delle istanze.
- Modifica il valore del campo dello spazio dei nomi se è diverso dallo spazio dei nomi instance1.
- Segui i passaggi specificati in Specifica dei certificati TLS in entrata per modificare la configurazione in entrata per l'altra istanza.
Per informazioni sulla configurazione dell'IP del bilanciatore del carico per l'altra istanza, consulta Gestione del gateway in entrata Apigee.
Imposta il contesto kubectl sul cluster originale prima di recuperare il nome del seed
kubectl config use-context original-cluster-name
Esegui il seguente comando kubectl per identificare un indirizzo host seed per Cassandra nella regione corrente.
kubectl get pods -o wide -n apigee -l app=apigee-cassandra
Qualsiasi IP del pod restituito dal comando precedente può essere considerato l'host seed multiregionale.
Nella seconda istanza, configura il valore di multiRegionSeedHost nel CR di apigee datastore in ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/apigee-datastore.yaml
Configurare la nuova istanza
Imposta il contesto sul cluster esistente
kubectl config use-context existing-cluster-name
Esporta il secret apigee-ca in un file
kubectl -n cert-manager get secret apigee-root-certificate -o yaml > apigee-root-certificate.yaml
Imposta il contesto sul nome del cluster della nuova regione:
kubectl config use-context NEW_CLUSTER_NAME
Importa il secret nel nuovo cluster
kubectl -n cert-manager apply -f apigee-root-certificate.yaml
Installa ibrido nella nuova istanza (regione) seguendo i passaggi descritti in Crea risorse di inizializzazione e controller.
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"
Crea un file di risorsa personalizzata (YAML) di replica dei dati Cassandra. Il file può avere qualsiasi nome. Negli esempi seguenti, il file avrà il nome datareplication.yaml. Il file deve contenere quanto segue:
apiVersion: apigee.cloud.google.com/v1alpha1 kind: CassandraDataReplication metadata: name: REGION_EXPANSION namespace: NAMESPACE spec: organizationRef: APIGEEORG_VALUE force: false source: region: SOURCE_REGION
Dove:
- REGION_EXPANSION è il nome che stai assegnando a questi metadati. Puoi scegliere un nome come "cassandra-data-replication".
- NAMESPACE è lo stesso spazio dei nomi scelto per la seconda istanza. che in genere è "apigee".
- APIGEEORG_VALUE è il valore restituito dal comando kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" nel passaggio precedente.
- SOURCE_REGION è il valore del valore del datacenter Cassandra dallo stato di nodetool del cluster di origine.
Applica CassandraDataReplication con il seguente comando:
kubectl apply -f datareplication.yaml
Verifica lo stato della ricompilazione utilizzando il seguente comando.
kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"
Il risultato dovrebbe essere simile a questo:
{ "rebuildDetails": { "apigee-cassandra-default-0": { "state": "complete", "updated": 1623105760 }, "apigee-cassandra-default-1": { "state": "complete", "updated": 1623105765 }, "apigee-cassandra-default-2": { "state": "complete", "updated": 1623105770 } }, "state": "complete", "updated": 1623105770 }
Verifica i processi di ricompilazione dai log. Inoltre, verifica le dimensioni dei dati utilizzando il comando nodetool status:
kubectl logs apigee-cassandra-default-0 -f -n apigee
Fai riferimento a datastore/secrets.yaml per JMX_user e JMX_password
kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool -u JMX_user -pw JMX_password status
Rimuovi
multiRegionSeedHost
dal CR del datastore Apigee ed esegui il comando riportato di seguito per applicare la modificakubectl apply k apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore
Controlla lo stato del cluster Cassandra
Il seguente comando è utile per verificare se la configurazione del cluster è riuscita in due data center. Il comando controlla lo stato di nodetool per le due regioni.
kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool -u JMX_user -pw JMX_password status
Datacenter: us-central1 ======================= Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.12.1.45 112.09 KiB 256 100.0% 3c98c816-3f4d-48f0-9717-03d0c998637f ra-1 UN 10.12.4.36 95.27 KiB 256 100.0% 0a36383d-1d9e-41e2-924c-7b62be12d6cc ra-1 UN 10.12.5.22 88.7 KiB 256 100.0% 3561f4fa-af3d-4ea4-93b2-79ac7e938201 ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.4.33 78.69 KiB 256 100.0% a200217d-260b-45cd-b83c-182b27ff4c99 ra-1 UN 10.0.0.21 78.68 KiB 256 100.0% 9f3364b9-a7a1-409c-9356-b7d1d312e52b ra-1 UN 10.0.1.26 15.46 KiB 256 100.0% 1666df0f-702e-4c5b-8b6e-086d0f2e47fa ra-1
Risoluzione dei problemi
Guida alla risoluzione dei problemi, alla diagnostica e all'assistenza
Pulizia manuale dopo l'utilizzo di forceDelete nella configurazione di Apigee Hybrid multiregionale
- Nel seguente esempio, ci sono due regioni:
us-east1
eus-west1
. - Nella regione
us-west1
, l'archivio dati Apigee è stato eliminato utilizzando l'eliminazione forzata. - Nella regione
us-east1
, Cassandra è ancora in esecuzione. Verifica che
apigeeds
sia stato eliminato utilizzando il comandokubectl get apigeeds -n apigee No resources found in apigee namespace.
Cambia il contesto kubectl con l'altra regione in cui il cluster Cassandra è ancora in esecuzione (in questo caso
us-east1
).Verifica che il datastore sia in esecuzione
kubectl get apigeeds -n apigee NAME STATE AGE default running 23h
Esegui l'accesso a uno dei pod Cassandra nella regione di cui è stato eseguito il provisioning (in questo caso
us-east1
)kubectl exec -it -n apigee apigee-cassandra-default-0 -- bash apigee@apigee-cassandra-default-0:~$
Controlla lo stato di nodetool, che mostrerà tutti i nodi inattivi nella regione eliminata (in questo caso
us-west1
)apigee@apigee-cassandra-default-0:~$ nodetool -u ${APIGEE_JMX_USER} -pw ${APIGEE_JMX_PASSWORD} status
Datacenter: us-east1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.52.0.212 685.01 KiB 256 ? e1aa61e3-4eae-4549-9b58-506d495d87ab ra-1 UN 10.52.0.72 606.75 KiB 256 ? 477dfc03-f93e-40ea-810a-d15769822ad5 ra-1 UN 10.52.0.104 648.3 KiB 256 ? a8854cff-c2e3-4f0c-a342-e692787efcab ra-1 Datacenter: us-west1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack DN 10.60.0.143 567.06 KiB 256 ? 355d6ace-ab77-42cb-8138-9993bfd62d0e ra-1 DN 10.60.0.40 535.99 KiB 256 ? 4ed2c903-ff56-40fa-a15e-80a3de3cb22d ra-1 DN 10.60.0.17 573.08 KiB 256 ? f9a50d19-c04a-4d0d-a088-612384bed9f5 ra-1
Rimuovi tutti i nodi nella regione eliminata (qui
us-west1
)apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode 355d6ace-ab77-42cb-8138-9993bfd62d0e apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode 4ed2c903-ff56-40fa-a15e-80a3de3cb22d apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode f9a50d19-c04a-4d0d-a088-612384bed9f5
Verifica che non siano rimasti nodi della regione eliminata (in questo caso
us-west1
)apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status
Datacenter: us-east1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.52.0.212 699.71 KiB 256 ? e1aa61e3-4eae-4549-9b58-506d495d87ab ra-1 UN 10.52.0.72 586.77 KiB 256 ? 477dfc03-f93e-40ea-810a-d15769822ad5 ra-1 UN 10.52.0.104 623.6 KiB 256 ? a8854cff-c2e3-4f0c-a342-e692787efcab ra-1
Una volta completata questa operazione, elimina il job di configurazione utente nella regione up (qui
us-east1
). Il job verrà ricreato automaticamente entro pochi secondi.kubectl get jobs -n apigee
NAME COMPLETIONS DURATION AGE apigee-cassandra-schema-setup-apigee--0d2504c 0/1 5m54s 5m54s apigee-cassandra-user-setup--apigee--0d2504c 0/1 7s 7s
kubectl delete job apigee-cassandra-user-setup--apigee--0d2504c
Attendi il completamento del job di configurazione utente
kubectl get jobs -n apigee
NAME COMPLETIONS DURATION AGE apigee-cassandra-schema-setup-apigee--0d2504c 1/1 5m54s 5m54s apigee-cassandra-user-setup--apigee--0d2504c 1/1 7m 7m
Verifica che gli spazi chiave non contengano la regione eliminata.
Crea un pod di debug di Cassandra.
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 chiaveddl_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)