Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Utilizzare un datastore Cassandra esterno

Questo argomento spiega come connettere un runtime Apigee hybrid a un datastore Cassandra in un cluster Kubernetes diverso. In questa configurazione, il cluster di runtime non ha pod Cassandra. Il nome di questa configurazione è modalità datastore esterno.

Topologia a due cluster

La modalità datastore esterno utilizza due cluster Kubernetes:

Il cluster Cassandra esegue l'anello Cassandra. Non esegue i componenti runtime ibridi.
Il cluster di runtime esegue i componenti di runtime ibrido, ma non ha pod Cassandra. I componenti di runtime si connettono all'anello Cassandra nel cluster Cassandra tramite la rete.

L'operatore Apigee viene eseguito in entrambi i cluster. Installa cert-manager, le definizioni di risorse personalizzate (CRD) di Apigee e il grafico apigee-operator in ogni cluster. La seguente tabella mostra i componenti di ogni cluster:

Componente	Cluster Cassandra	Cluster di runtime
cert-manager	Sì	Sì
CRD Apigee e grafico `apigee-operator`	Sì	Sì
Grafico `apigee-datastore`	Sì, con i pod Cassandra	Sì, con `replicaCount: 0` e nessun pod Cassandra
Tutti gli altri grafici ibridi, ad esempio `apigee-telemetry`, `apigee-redis`, `apigee-ingress-manager`, `apigee-org`, `apigee-env` e `apigee-virtualhost`	No	Sì

L'operatore Apigee svolge un'attività diversa in ogni cluster:

Nel cluster Cassandra, l'operatore crea i pod Cassandra. Gestisce anche il ciclo di vita di Cassandra, ad esempio quando ridimensioni l'anello.
Nel cluster di runtime, l'operatore non crea pod Cassandra. Crea un servizio headless e un oggetto Endpoints che puntano all'anello Cassandra nel cluster Cassandra. Se attivi la sincronizzazione dinamica degli endpoint, l'operatore nel cluster di runtime legge anche gli endpoint Cassandra dal cluster Cassandra.

Panoramica della configurazione

Esegui questi passaggi nella sequenza indicata di seguito. La sequenza è importante. L'autorità di certificazione (CA) condivisa deve trovarsi nel cluster di runtime prima che questo emetta i certificati. Per saperne di più, vedi Condividere la CA Apigee prima di installare l'operatore.

Nel cluster Cassandra, installa cert-manager, le CRD Apigee, il grafico apigee-operator e il grafico apigee-datastore.
Assicurati che i pod Cassandra nel cluster Cassandra siano pronti.
Nel cluster di runtime, installa cert-manager.
Copia il secret apigee-ca dal cluster Cassandra al cluster di runtime. Esegui questo passaggio prima di installare il grafico apigee-operator nel cluster di runtime.
Nel cluster di runtime, installa i componenti di runtime ibrido. Utilizza gli override dell'archivio dati esterno per il grafico apigee-datastore. Utilizza le stesse credenziali Cassandra del cluster Cassandra.
(Consigliato) Attiva la sincronizzazione dinamica degli endpoint.
Verifica la connessione.

Per i passaggi di installazione di ogni grafico, vedi Installare Apigee hybrid utilizzando Helm.

Prima di iniziare

Assicurati che il tuo ambiente soddisfi i seguenti requisiti:

Connessione di rete a Cassandra. Il cluster di runtime deve connettersi ai pod Cassandra sulla porta TCP 9042. Inserisci i due cluster in un VPC condiviso o in reti con una connessione privata tra loro.
Una regione. Inserisci i due cluster nella stessa regione. Il tempo di round trip tra i cluster aumenta la latenza di ogni richiesta di runtime.
cert-manager in entrambi i cluster. In ogni cluster, cert-manager emette i certificati per la connessione mTLS tra il runtime e Cassandra. Installa cert-manager nel cluster Cassandra e nel cluster di runtime.
Un percorso per ogni pod Cassandra. Il driver client Cassandra si connette direttamente a ogni pod Cassandra. Il cluster di runtime deve connettersi all'indirizzo IP di ogni pod Cassandra, non solo a un indirizzo. Un bilanciatore del carico o un singolo indirizzo IP virtuale davanti all'anello non soddisfa questo requisito.
Connessione di rete al server dell'API Kubernetes. Questo requisito si applica solo se utilizzi la sincronizzazione dinamica degli endpoint. Il cluster di runtime deve connettersi al server API Kubernetes del cluster Cassandra.

Condividi la CA Apigee prima di installare l'operatore

Copia il secret apigee-ca nel cluster di runtime prima di installare il grafico apigee-operator nel cluster di runtime.

Il runtime e Cassandra utilizzano mTLS, quindi i due cluster devono considerare attendibile la stessa CA. Il grafico apigee-operator crea una CA autofirmata in ogni cluster. Questa CA è un cert-manager Certificate denominato apigee-ca nello spazio dei nomi cert-manager.

Se ogni cluster crea il proprio apigee-ca, le due CA hanno impronte diverse. L'handshake mTLS non riesce e il runtime non può connettersi a Cassandra.

Se il secret apigee-ca è già presente nel cluster, cert-manager non lo sostituisce. Pertanto, se copi prima il secret, il cluster di runtime utilizza la CA condivisa. Se il cluster di runtime ha emesso certificati da una CA diversa, una copia del secret non è sufficiente. Devi anche ricreare questi certificati in modo che vengano firmati dalla CA condivisa.

Installa cert-manager nel cluster di runtime. Quindi copia il secret CA dal cluster Cassandra al cluster di runtime:

kubectl --context CASSANDRA_CLUSTER -n cert-manager get secret apigee-ca -o yaml \
  | grep -v -E '^\s+(resourceVersion|uid|creationTimestamp|selfLink):' \
  | kubectl --context RUNTIME_CLUSTER -n cert-manager apply -f -

Sostituisci quanto segue:

CASSANDRA_CLUSTER: il contesto kubectl del cluster Cassandra.
RUNTIME_CLUSTER: il contesto kubectl del cluster di runtime.

Il comando grep rimuove i campi dei metadati appartenenti al cluster Cassandra. Il server API Kubernetes non crea un oggetto con un valore resourceVersion.

Le installazioni multiregionali utilizzano lo stesso principio della CA condivisa. Per un passaggio di copia simile, vedi Ruotare il certificato CA radice. Per la configurazione mTLS di Cassandra, consulta Configura l'autenticazione per Cassandra.

Utilizza le stesse credenziali Cassandra in entrambi i cluster

Utilizza uno di questi metodi nei file di override dei due cluster:

Imposta gli stessi nomi utente e password in cassandra.auth: default, admin, ddl, dml, jmx e jolokia.
Imposta cassandra.auth.secret. In ogni cluster, il secret deve contenere gli stessi utenti e password. Vedi Creare il secret.
Imposta cassandra.auth.secretProviderClass su SecretProviderClass che legge lo stesso archivio dei secret. Consulta Memorizzazione dei secret di Cassandra in Hashicorp Vault.

Non copi il secret delle credenziali dal cluster Cassandra. Il grafico nel cluster di runtime crea il secret dagli override. Per trovare un errore di autenticazione, consulta Verifica la connessione.

Configurare l'archivio dati esterno

Nel cluster di runtime, il grafico apigee-datastore non deve creare pod Cassandra. Deve puntare all'anello Cassandra nel cluster Cassandra. Aggiungi queste impostazioni cassandra al file di override del cluster di runtime:

cassandra:
  # No Cassandra pods in the runtime cluster.
  replicaCount: 0
  properties:
    # A comma-separated list of the Cassandra pod IP addresses.
    externalHost: "CASSANDRA_IP_ADDRESSES"
  storage:
    # Required, even with replicaCount: 0.
    storageSize: "10Gi"

Dove:

CASSANDRA_IP_ADDRESSES è un elenco separato da virgole degli indirizzi IP dei pod Cassandra nel cluster Cassandra. Ad esempio: 10.0.0.1:9042,10.0.0.2:9042,10.0.0.3:9042. Il suffisso :9042 è facoltativo. Per ottenere l'elenco, esegui questo comando:
```
kubectl --context CASSANDRA_CLUSTER -n APIGEE_NAMESPACE get pods -l app=apigee-cassandra \
  -o jsonpath='{.items[*].status.podIP}' | tr ' ' ','
```
APIGEE_NAMESPACE è il tuo spazio dei nomi Apigee. Il valore predefinito è apigee.
replicaCount: 0 indica all'operatore di non creare pod Cassandra nel cluster di runtime. L'operatore crea un servizio headless e un oggetto Endpoints che puntano agli indirizzi externalHost.
cassandra.properties.externalHost è un elenco separato da virgole di indirizzi IP Cassandra. Ogni indirizzo può avere un suffisso :port, ma l'operatore ignora la porta e utilizza sempre la porta 9042. L'operatore accetta solo indirizzi IP. Ignora i nomi host e i nomi DNS e scrive un avviso nel log per ogni voce ignorata.
cassandra.storage.storageSize è obbligatorio, ma il cluster di runtime non crea PersistentVolume per Cassandra. Il webhook di convalida ApigeeDatastore controlla sempre storageSize. Utilizza una quantità valida, ad esempio 10Gi.

Nota:il grafico apigee-datastore include un esempio completo di questi override in apigee-datastore/examples/external-datastore-values.yaml.

L'indirizzo IP di un pod cambia quando viene scalato l'anello e quando Kubernetes riprogramma un pod. Di conseguenza, l'elenco in externalHost diventa errato. Pertanto, ti consigliamo la sincronizzazione dinamica degli endpoint. La sincronizzazione dinamica degli endpoint mantiene aggiornato automaticamente l'elenco degli indirizzi IP dei pod Cassandra. Utilizza externalHost da solo solo per un'installazione semplice o per la configurazione iniziale.

Mantieni aggiornati gli endpoint con la sincronizzazione dinamica degli endpoint

Con solo externalHost, devi modificare gli override ogni volta che l'anello Cassandra cambia. La sincronizzazione dinamica degli endpoint rimuove questo passaggio manuale. L'operatore nel cluster di runtime legge gli endpoint Cassandra pronti dal cluster Cassandra a intervalli regolari. Poi copia questi endpoint nell'oggetto Endpoints nel cluster di runtime.

Ti consigliamo la sincronizzazione dinamica degli endpoint. Gli indirizzi IP dei pod cambiano ogni volta che viene scalato il ring o Kubernetes riprogramma un pod. La sincronizzazione dinamica degli endpoint legge gli indirizzi IP dei pod pronti del servizio headless Cassandra. Pertanto, l'oggetto Endpoints nel cluster di runtime contiene sempre gli indirizzi IP dei pod Cassandra attuali.

Con la sincronizzazione dinamica degli endpoint, externalHost è ancora necessario. L'operatore lo utilizza in queste due condizioni:

Prima della prima lettura riuscita dal cluster Cassandra.
Quando una lettura dal cluster Cassandra non va a buon fine e non ci sono endpoint da una lettura riuscita precedente.

Se una lettura non va a buon fine e sono presenti endpoint di una lettura precedente riuscita, l'operatore li conserva. Il runtime mantiene la connessione a Cassandra.

Per attivare la sincronizzazione dinamica degli endpoint, aggiungi il blocco externalEndpointsSync al file di override del cluster di runtime:

cassandra:
  replicaCount: 0
  properties:
    # The first endpoints, and the fallback if a read fails.
    externalHost: "CASSANDRA_IP_ADDRESSES"
    externalEndpointsSync:
      # A secret in the runtime cluster. Its "kubeconfig" key holds the
      # kubeconfig for the Cassandra cluster.
      secretRef: apigee-remote-cass-kubeconfig
      # The namespace of the Cassandra headless Service in the Cassandra cluster.
      namespace: apigee
      # The Cassandra headless Service in the Cassandra cluster.
      serviceName: apigee-cassandra-default
      # The interval between reads, in seconds. The default is 30.
      intervalSeconds: 30
  storage:
    storageSize: "10Gi"

Nota:il grafico apigee-datastore include un esempio completo di questi override in apigee-datastore/examples/external-datastore-endpoint-sync-values.yaml.

Crea un account di servizio di sola lettura nel cluster Cassandra

L'operatore nel cluster di runtime utilizza un kubeconfig per connettersi al cluster Cassandra. Questo kubeconfig deve utilizzare un ServiceAccount di sola lettura con privilegi minimi. Questo service account può leggere solo gli endpoint Cassandra. Non può modificare le risorse nel cluster Cassandra.

Nel cluster Cassandra, crea queste risorse:

Un service account, ad esempio apigee-endpoint-reader.
Un ruolo e un RoleBinding nello spazio dei nomi Cassandra. Il ruolo concede solo i verbi get, list e watch su endpoints di base. Non fornire altri verbi, ad esempio create, update, patch o delete. Non concedere l'accesso ad altre risorse.
Un secret token di lunga durata per ServiceAccount.

Poi crea un file kubeconfig per il server API Kubernetes del cluster Cassandra. Questo kubeconfig deve utilizzare il token di ServiceAccount. Nel cluster di runtime, crea un secret con il nome che hai impostato in externalEndpointsSync.secretRef. Inserisci il kubeconfig nella chiave kubeconfig:

kubectl --context RUNTIME_CLUSTER -n APIGEE_NAMESPACE create secret generic \
  apigee-remote-cass-kubeconfig --from-file=kubeconfig=READER_KUBECONFIG_FILE

Sostituisci READER_KUBECONFIG_FILE con il percorso del file kubeconfig per il ServiceAccount di sola lettura.

Il file kubeconfig contiene un token di lunga durata. Mantieni questo secret sicuro come le altre credenziali.

Nota: il grafico apigee-datastore include un campione di queste risorse in apigee-datastore/examples/external-cassandra-reader-rbac.yaml. L'esempio include ServiceAccount, Role, RoleBinding, Secret del token e Secret kubeconfig per il cluster di runtime.

Monitorare la sincronizzazione degli endpoint dinamici

Se una lettura dal cluster Cassandra non riesce, il runtime mantiene la connessione. ma gli endpoint nel cluster di runtime non cambiano finché una lettura non ha di nuovo esito positivo. Monitora la sincronizzazione in modo da trovare un errore persistente prima che l'anello Cassandra cambi.

L'operatore nel cluster di runtime fornisce questi indicatori:

La condizione EndpointSyncDegraded nello stato della risorsa ApigeeDatastore. La condizione diventa True dopo tre letture non riuscite consecutive. Il motivo è RemoteReadFailed o NoReadyRemoteEndpoints. Dopo una lettura riuscita, la condizione diventa False con il motivo SyncSucceeded.
La metrica external_endpoint_sync_last_success_timestamp. Questa metrica è l'ora dell'ultima lettura riuscita, in secondi Unix.
La metrica external_endpoint_sync_failures_total. Questa metrica conteggia le letture non riuscite.

Le due metriche hanno le etichette namespace e name della risorsa ApigeeDatastore. L'operatore le mostra nel suo endpoint delle metriche.

Per visualizzare la condizione, esegui questo comando:

kubectl --context RUNTIME_CLUSTER -n APIGEE_NAMESPACE get apigeedatastore default \
  -o jsonpath='{.status.conditions}'

Ti consigliamo un avviso per la condizione EndpointSyncDegraded. Lo stato ApigeeDatastore mantiene la condizione quando l'operatore riavvia. Solo una lettura riuscita imposta la condizione su False.

Se utilizzi anche un avviso sulla metrica, invia un avviso quando una di queste due espressioni è vera:

time() - external_endpoint_sync_last_success_timestamp > 300
absent(external_endpoint_sync_last_success_timestamp)

L'operatore imposta la metrica solo dopo una lettura riuscita. Se l'operatore si riavvia mentre le letture non vanno a buon fine, la metrica non è presente. Quindi la prima espressione non corrisponde e solo la seconda espressione invia l'avviso.

Verificare la connessione

Dopo aver installato i componenti runtime, esegui questi controlli nel cluster runtime:

Assicurati che il cluster di runtime non abbia pod Cassandra:
```
kubectl --context RUNTIME_CLUSTER -n APIGEE_NAMESPACE get pods -l app=apigee-cassandra
```
L'output è No resources found.
Assicurati che l'oggetto Endpoints punti all'anello Cassandra:
```
kubectl --context RUNTIME_CLUSTER -n APIGEE_NAMESPACE get endpoints apigee-cassandra-default
```
La colonna ENDPOINTS mostra gli indirizzi IP di Cassandra. Se utilizzi la sincronizzazione dinamica degli endpoint, questi sono gli indirizzi IP dei pod Cassandra pronti nel cluster Cassandra.
Assicurati che i job di configurazione di Cassandra siano stati completati:
```
kubectl --context RUNTIME_CLUSTER -n APIGEE_NAMESPACE get jobs \
  | grep -E 'apigee-cassandra-(schema|user)-setup'
```
La colonna COMPLETIONS mostra 1/1 per ogni job. Se un job non viene completato, esamina il log del job per verificare la presenza di errori di autenticazione. Poi assicurati che i due cluster utilizzino le stesse credenziali Cassandra.

Scalare l'anello Cassandra

L'operatore Apigee nel cluster Cassandra è proprietario del ciclo di vita di Cassandra. Scala Cassandra nel cluster Cassandra. Non puoi scalare Cassandra dal cluster di runtime.

Rispetta le stesse regole di un anello Cassandra nel cluster di runtime:

Scala Cassandra in multipli di tre. In questo modo, l'anello viene bilanciato su tre zone di disponibilità.
Prima di aumentare il numero di pod, assicurati che il cluster Cassandra abbia una capacità dei nodi sufficiente.
Se non utilizzi la sincronizzazione dinamica degli endpoint, aggiorna externalHost dopo ogni operazione della bilancia.

Per ulteriori informazioni, vedi Scalabilità di Cassandra.

Passaggi successivi

Per installare i grafici in ogni cluster, vedi Installare Apigee Hybrid utilizzando Helm.
Per mTLS e le credenziali di Cassandra, consulta Configura l'autenticazione per Cassandra.
Per aggiungere capacità all'anello Cassandra, vedi Scalabilità di Cassandra.