SCAFFO DI CONTROLLO DA PARTE DELL'UTENTE SULL'INNOVAZIONE IN KUBERNETES
Operatore Couchbase per Kubernetes
L'operatore Kubernetes si occupa della distribuzione, della scalabilità, della risoluzione dei problemi e dell'aggiornamento di Couchbase per voi. Il vostro team di piattaforma gestisce il database come qualsiasi altro workload, senza i problemi delle pagine del mattino alle 2 di notte.

Kubernetes conosce i pod; noi conosciamo Couchbase.
Kubernetes è ottimo per sostituire i pod. Anche un database richiede un riequilibrio, la collocazione delle repliche e aggiornamenti sicuri. Il nostro operatore si occupa di tutto questo per voi.

Naviga più velocemente sulla piattaforma che già utilizzi
Quando la database è all’esterno della vostra piattaforma, ogni modifica viene registrata tramite un ticket. Qui si tratta di YAML in Git, verificato e inviato come codice.

Rimani sempre aggiornato senza interruzioni durante i periodi di manutenzione settimanali
Le upgrade vengono rinviate e il rischio di sicurezza aumenta. Le versioni aggiornate vengono installate una alla volta mentre le app sono in esecuzione e si può tornare indietro a metà del processo.

Meno interruzioni di servizio, meno pagine alle 2 di notte
Quando un pod o un nodo si guasta, l’operatore lo sostituisce, riutilizza il suo storage e riequilibra i dati. Rappresenta solo ciò che richiede un intervento umano.

Mantieni il controllo sui tuoi dati e sulle tue spese
Utilizzate la capacità Kubernetes già implementata, sia in locale che in qualsiasi cloud. Rispetta le norme sulla residenza dei dati e sulla conformità, alle tue condizioni.
Cos'è l'operatore Couchbase Kubernetes?
Couchbase Server viene eseguito su Kubernetes per voi. Vi basta dire cosa volete nel formato YAML e l’operatore gestisce la configurazione del cluster, mantenendone gli stessi parametri.
L’operatore aggiunge tipi di Couchbase a Kubernetes, come CouchbaseCluster, CouchbaseBucket e CouchbaseBackup. Scrivi ciò che desideri e l’operatore confronta ciò che è in esecuzione con quello che è stato scritto e corregge la differenza, tutto il giorno. Un controller di ammissione rifiuta le configurazioni sbagliate prima di salvarle, quindi gli errori vengono visualizzati nel terminale anziché nel canale di incidenti.
Un StatefulSet generico riavvia i pod. L’operatore riconosce Couchbase. Ricalibra i dati prima di procedere, colloca le repliche in diverse zone e riutilizza i volumi persistenti in modo che un pod sostituito recuperi solo gli ultimi cambiamenti. Durante gli aggiornamenti di Kubernetes, permette che solo un pod Couchbase venga avviato alla volta, in modo che i flussi di dati non perdano dati.
La versione 2.9 supporta Kubernetes 1.31 a 1.36, Red Hat OpenShift 4.18 a 4.20, Amazon EKS, Google GKE, Microsoft AKS, K3s e Bottlerocket OS, su x86 o ARM. Se sta usando qualcosa di diverso? Un tool di auto-certificazione verifica la piattaforma, lo storage e la rete, e Couchbase esamina i risultati. L’utilizzo in locale è anche possibile, con immagini dal proprio registro di sistema.
L’operatore utilizza la versione 7.2 fino alla 8.0 di Couchbase Server Enterprise Edition. Si tratta della stessa piattaforma utilizzata da Capella, quindi i vostri SDK, le query SQL++ e il modello di dati funzionano ovunque. La replicazione tra data center (XDCR) collega i cluster su Kubernetes, le VM e la piattaforma Capella, quindi passare da una soluzione a un’altra o spostarsi tra di esse è una semplice modifica della configurazione, non un progetto di migrazione.
Funziona in modalità Auto Pilot, una pod alla volta con cura
5 su 5
Livello di funzionalità dell'operatore Kubernetes: Auto Pilot, la categoria superiore
1 pod
La maggior parte degli operatori consente a Kubernetes di espellere gli utenti contemporaneamente durante gli aggiornamenti.
RISULTATI PER I CLIENTI DI COUCHBASE SERVER
Costruito per applicazioni che non possono essere interrotte
Sotto il cofano
Tutto ciò di cui le operazioni di giorno 2 hanno bisogno, gestito in YAML
Come l’operatore gestisce, dimensiona, aggiorna, protegge e mantiene la sicurezza di Couchbase, così il tuo team non dovrà farlo manualmente.
- Operare
- Scala
- Aggiornamento
- Proteggere
- Sicuro
Installa con Helm, gestiscilo tramite Git e controlla tutto attraverso gli strumenti già utilizzati dal team dell'azienda.
Le principali funzionalità, tra cui le novità di Operator 2.9
Helm, GitOps e la CLI
Un grafico Helm ufficiale installa l'operatore, il controller di ammissione, un cluster e persino Sync Gateway. Conserva ogni modifica nel Git.
Una configurazione sbagliata non dà mai risultati positivi
Il controller di ammissione controlla ogni risorsa Couchbase prima che Kubernetes la salvi, includendo segreti, certificati e classi di storage.
Avvisi quando è necessario un intervento umano
Un watchdog segnala ciò che l’operatore non riesce a risolvere da solo, come certificati scaduti o quorum perso, tramite eventi e metriche Kubernetes.
Scala ogni servizio Couchbase separatamente, automaticamente se preferisci, e disabilita i cluster inattivi.
Le principali funzionalità, tra cui le novità di Operator 2.9
Scala multidimensionale
Offrite ai dati, agli indici, alle query, alla ricerca e all’analisi i propri pod e hardware. Aggiungete i pod di ricerca senza dover pagare per altri pod di dati.
Autoscale con il Kubernetes HPA
Misura ogni servizio in base alle metriche CPU, memoria o Couchbase tramite l'Horizontal Pod Autoscaler. Nessun downtime durante l'avvio e lo spegnimento dei pod.
Hibernate i cluster inattivi
Impostare dev e test cluster in modalità dormiente con un solo campo. Il calcolo torna nel pool, i volumi restano lì e il cluster si avvia come prima.
Aggiornate Couchbase e Kubernetes senza interruzioni e trasferite i cluster esistenti su Kubernetes, mantenendo il servizio attivo.
Le principali funzionalità, tra cui le novità di Operator 2.9
Aggiornamenti progressivi gestibili da te
Modifichi l'immagine tag e l'operatore aggiorna il pod per pod. Imposta l'ordine per zona, classe o servizio e interrotta i passaggi tra di loro.
Aggiornamenti di Kubernetes senza perdita di dati
I budget per la disattivazione e i gate di prontezza consentono ai nodi di eliminare un pod di Couchbase alla volta e solo una volta che i dati sono stati riequilibrati in modo sicuro.
Trasferire i cluster di VM su Kubernetes
Incentra l'operatore su un cluster di VM o di EC2. Questo fa scambiare i nodi in Kubernetes uno alla volta, mentre le applicazioni continuano a funzionare.
Backup programmati su storage oggetti, repliche tra cluster e repliche distribuite tra le zone.
Le principali funzionalità, tra cui le novità di Operator 2.9
Backup e ripristino programmati
Configura gli orari come risorse Kubernetes. Le copie di backup vengono eseguite dai tuoi nodi Couchbase e possono essere archiviate su S3, Azure Blob o Google Cloud Storage.
XDCR tra i cluster
Riprodurre l'operazione su un altro cluster Kubernetes, una regione o un cloud, in un solo modo o in entrambi. Nuova funzionalità in 2.9: registrazione dei conflitti nelle configurazioni active-active.
Posizionamento consapevole della zona
I gruppi di server sono mappati alle zone di disponibilità, quindi le repliche vengono ospitate in una zona diversa rispetto ai dati che proteggono. Se una zona viene persa, i dati rimangono intatti.
TLS che si ruota da solo, crittografia in attesa con le proprie chiavi e utenti e ruoli mantenuti nel codice.
Le principali funzionalità, tra cui le novità di Operator 2.9
TLS che si ruota da sé
Utilizzate i segreti standard di Kubernetes TLS o il tool cert-manager. Rotate i certificati del server, del client o della CA e richiedete il TLS reciproco se lo desiderate.
Crittografia in attesa, le tue chiavi
Per Server 8.0: crittografare i bucket, la configurazione e i log di audit con chiavi da AWS KMS, un gestore di chiavi KMIP o da Couchbase stesso.
Utilizzatori, ruoli e LDAP come codice
Definire gli utenti, i gruppi e le vincoli di ruolo di Couchbase come risorse Kubernetes, collegare i gruppi LDAP e ruotare in modo sicuro la password dell'amministratore.
- Produzione
- Hybrid
- Migrare
ARCHITETTURA
Un cluster produttivo in 3 zone

Un’interruzione della rete in una delle zone non dovrebbe compromettere l’operatività dell’app. Ogni zona diventa un gruppo di server Couchbase su nodi riservati a questo servizio, quindi le repliche vengono ospitate altrove. Ogni servizio ha i propri pod e lo storage nella propria zona. cert-manager ruota il protocollo TLS e i backup vengono gestiti dai nodi della database.
ARCHITETTURA
Una topologia per ogni sito

Alcuni dati devono rimanere in locale. Alcune app vivono nel cloud. Esegui lo stesso YAML operatore su OpenShift nel tuo data center e su EKS, AKS o GKE, quindi collega i due sistemi con XDCR in entrambe le direzioni. I filtri mantengono i documenti regolamentati all’interno del paese. Aggiungi Capella nelle regioni in cui preferisci non eseguire nulla.
ARCHITETTURA
Passare da un VM all'altro senza uscire dal sistema

Descrivete il vostro cluster esistente in YAML e puntate l’operatore su di esso. Questo aggiunge un pod, riequilibra i dati su di esso e poi rimuove un nodo VM, uno per volta, mentre le applicazioni rimangono connesse a un unico cluster. Scegliete l’ordine e il ritmo e potete interrompere la fase iniziale in caso di configurazione ibrida.

PER INIZIARE
Dal lancio di Helm al primo cluster
Aggiungi il repo di Couchbase Helm e installa un grafico. Ottieni l'operatore, il controller di ammissione e un cluster di Couchbase funzionante, pronti per la connessione dalla console web o tramite un SDK. Preferisci procedere passo dopo passo? La CLI installa ogni componente separatamente, su Kubernetes o OpenShift. Leggi la guida sulle migliori pratiche prima della produzione. Copre lo storage, la schedulazione e gli errori da evitare.
Lo stesso motore, tre modi per usarlo
Autogestione
Couchbase Server
Il motore utilizzato dall'operatore: JSON, key-value, SQL++, ricerca, ricerca vettoriale e caching in un'unica database. Eseguietelo su Kubernetes con l'operatore oppure su VM e bare metal, a seconda delle vostre esigenze.
CLOUD MANEGGIATO
Couchbase Capella
Vuoi avere Couchbase senza utilizzare Kubernetes? Capella è lo stesso motore, completamente gestito su AWS, Google Cloud e Azure. Couchbase gestisce l'installazione, i backup, lo scaling e gli aggiornamenti.
MOBILE E EDGE
Couchbase Mobile
Couchbase Lite mantiene le applicazioni operative sui telefoni e sui dispositivi edge senza connessione. Lo stesso Helm chart può essere utilizzato per distribuire Sync Gateway accanto al cluster per mantenere i dispositivi sincronizzati.
FAQ sull'operatore Couchbase Kubernetes
Risposte alle domande più frequenti relative all'esecuzione di Couchbase su Kubernetes e OpenShift.
Il nostro gestore Kubernetes, noto anche come Couchbase Autonomous Operator (CAO), implementa, dimensiona, ripristina, fa backup e aggiorna il server Couchbase gestito autonomamente su Kubernetes e OpenShift.
La versione 2.9 supporta Kubernetes 1.31 a 1.36, OpenShift 4.18 a 4.20, Amazon EKS, Google GKE, Microsoft AKS, K3s e Bottlerocket OS su nodi x86 e ARM.
Gestisce le versioni 7.2-8.0 di Couchbase Server Enterprise Edition. L’operatore 2.9 inoltre configura le funzionalità di 8.0, come l’encryption in rest. La Community Edition non è supportata.
Il Framework Operator definisce cinque livelli di funzionalità, dal Basic Install al Auto Pilot. L'operatore Couchbase è classificato al livello 5, Auto Pilot. I vendor valutano le proprie prestazioni, quindi provatelo e giudicate voi stessi.
Sì. Inserite l'operatore in un cluster di VM o EC2 e il sistema lo riequilibra automaticamente i nodi in Kubernetes uno alla volta. Le applicazioni rimangono connesse e entrambe le parti necessitano di accesso alla rete.
Entrambi utilizzano lo stesso motore di Couchbase. Con l'operatore, il tuo team gestisce Couchbase nel proprio Kubernetes. Con Capella, Couchbase lo gestisce per te su AWS, Google Cloud o Azure.



