Containere er blevet mere og mere populære for udviklere, der ønsker at implementere applikationer i skyen. For at administrere disse nye applikationer er Kubernetes blevet en de facto standard for containerorkestrering. Kubernetes gør det muligt for udviklere at oprette distribuerede applikationer, der automatisk skaleres elastisk afhængigt af efterspørgsel.
Kubernetes blev udviklet til ubesværet implementering, skalering og styring af statsløse applikationsarbejdsbelastninger i produktionen. Når det kommer til stateful, cloud-native data, har der været behov for den samme lette implementering og skala.
I distribuerede databaser appellerer Cassandra til udviklere, der ved, at de bliver nødt til at skalere deres data - det giver en fuldt fejltolerant database og tilgang til datastyring, der kan køre på samme måde på tværs af flere placeringer og cloud-tjenester. Da alle noder i Cassandra er ens, og hver node er i stand til at håndtere læse- og skriveanmodninger, er der ikke et enkelt fejlpunkt i Cassandra-modellen. Data replikeres automatisk mellem fejlzoner for at forhindre tab af en enkelt forekomst, der påvirker applikationen.
Forbinder Cassandra til Kubernetes
Det logiske næste trin er at bruge Cassandra og Kubernetes sammen. Når alt kommer til alt at få en distribueret database til at køre sammen med et distribueret applikationsmiljø, bliver det lettere at få data- og applikationsoperationer til at foregå tæt på hinanden. Ikke kun undgår dette latens, det kan hjælpe med at forbedre ydeevnen i skala.
For at opnå dette betyder det imidlertid at forstå, hvilket system der har ansvaret. Cassandra har allerede den slags fejltolerance og node-placering, som Kubernetes kan levere, så det er vigtigt at vide, hvilket system der har ansvaret for at træffe beslutningerne. Dette opnås ved hjælp af en Kubernetes-operatør.
Operatører automatiserer processen med at implementere og administrere mere komplekse applikationer, der kræver domænespecifik information og har brug for at interagere med eksterne systemer. Indtil operatører blev udviklet, førte stateful applikationskomponenter som databaseinstanser til ekstra ansvar for devops-hold, da de var nødt til at udføre manuelt arbejde for at få deres forberedelser forberedt og køre på en statefuld måde.
Der er flere operatører for Cassandra, der er udviklet af Cassandra-samfundet. I dette eksempel bruger vi cass-operator, som blev sat sammen og open-sourced af DataStax. Det understøtter open source Kubernetes, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) og Pivotal Container Service (PKS), så du kan bruge den Kubernetes-tjeneste, der bedst passer til dit miljø.
Installation af en kassoperatør på din egen Kubernetes-klynge er en simpel proces, hvis du har grundlæggende viden om at køre en Kubernetes-klynge. Når din Kubernetes-klynge er godkendt ved hjælp af kubectl, er Kubernetes-klyngens kommandolinjeværktøj og din Kubernetes-skyinstans (hvad enten open source Kubernetes, GKE, EKS eller PKS) er forbundet til din lokale maskine, kan du begynde at anvende operatørkonfiguration YAML-filer til din klynge.
Opsætning af dine kassoperatørdefinitioner
Det næste trin er at anvende definitionerne for kassoperatørmanifestet, lagringsklassen og datacentret til Kubernetes-klyngen.
En hurtig note om definitionen af datacenteret. Dette er baseret på definitionerne i Cassandra snarere end en henvisning til et fysisk datacenter.
Hierarkiet for dette er som følger:
- En node refererer til et computersystem, der kører en forekomst af Cassandra. En node kan være en fysisk vært, en maskininstans i skyen eller endda en Docker-container.
- Et rack henviser til et sæt Cassandra-knudepunkter i nærheden af hinanden. Et rack kan være et fysisk rack, der indeholder noder forbundet til en fælles netværksafbryder. I skyinstallationer henviser et rack imidlertid ofte til en samling af maskinforekomster, der kører i den samme tilgængelighedszone.
- Et datacenter refererer til en samling af logiske stativer, der generelt er bosat i samme bygning og forbundet med et pålideligt netværk. I skyinstallationer kortlægges datacentre generelt til en skyregion.
- En klynge henviser til en samling af datacentre, der understøtter den samme applikation. Cassandra-klynger kan køre i et enkelt skymiljø eller fysisk datacenter eller distribueres på flere steder for større modstandsdygtighed og reduceret ventetid
Nu har vi bekræftet vores navngivningskonventioner, det er tid til at konfigurere definitioner. Vores eksempel bruger GKE, men processen ligner andre Kubernetes-motorer. Der er tre trin.
Trin 1
Først skal vi køre en kubectl-kommando, der refererer til en YAML-konfigurationsfil. Dette anvender kassoperatørmanifestets definitioner på den tilsluttede Kubernetes-klynge. Manifester er API-objektbeskrivelser, der beskriver objektets ønskede tilstand, i dette tilfælde din Cassandra-operatør. For et komplet sæt versionsspecifikke manifest, se denne GitHub-side.
Her er et eksempel på en kubectl-kommando til GKE-sky, der kører Kubernetes 1.16:
kubectl create -f //raw.githubusercontent.com/datastax/cass-operator/v1.3.0/docs/user/cass-operator-manifests-v1.16.yaml
Trin 2
Den næste kubectl-kommando anvender en YAML-konfiguration, der definerer de lagerindstillinger, der skal bruges til Cassandra-noder i en klynge. Kubernetes bruger StorageClass-ressourcen som et abstraktionslag mellem bælg, der har brug for vedvarende lagring, og de fysiske lagerressourcer, som en bestemt Kubernetes-klynge kan levere. Eksemplet bruger SSD som lagringstype. For flere muligheder, se denne GitHub-side. Her er det direkte link til YAML anvendt i lagringskonfigurationen nedenfor:
apiVersion: storage.k8s.io/v1slags: StorageClass
metadata:
navn: server-lager
forsyner: kubernetes.io/gce-pd
parametre:
type: pd-ssd
replikeringstype: ingen
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Slet
Trin 3
Endelig bruger vi kubectl igen, vi anvender YAML, der definerer vores Cassandra Datacenter.
# Størrelse til at arbejde på 3 k8s medarbejdernoder med 1 kerne / 4 GB RAM# Se naboeksempel-cassdc-full.yaml for dokumenter for hver parameter
apiVersion: cassandra.datastax.com/v1beta1
art: CassandraDatacenter
metadata:
navn: dc1
spec:
clusterName: cluster1
serverType: cassandra
serverVersion: "3.11.6"
managementApiAuth:
usikker: {}
størrelse: 3
storageConfig:
cassandraDataVolumeClaimSpec:
storageClassName: server-storage
accessModes:
- ReadWriteOnce
ressourcer:
anmodninger:
opbevaring: 5Gi
config:
Cassandra-yaml:
autentifikator: org.apache.cassandra.auth.PasswordAuthenticator
autorisator: org.apache.cassandra.auth.CassandraAuthorizer
role_manager: org.apache.cassandra.auth.CassandraRoleManager
jvm-muligheder:
initial_heap_size: "800M"
max_heap_size: "800M"
Dette eksempel YAML er for et open source Apache Cassandra 3.11.6-billede med tre noder på et rack i Kubernetes-klyngen. Her er det direkte link. Der er et komplet sæt databasespecifikke datacenterkonfigurationer på denne GitHub-side.
På dette tidspunkt kan du se på de ressourcer, du har oprettet. Disse vil være synlige i din cloud-konsol. I Google Cloud Console kan du for eksempel klikke på fanen Klynger for at se, hvad der kører, og se på arbejdsbelastningen. Disse er implementerbare computerenheder, der kan oprettes og styres i Kubernetes-klyngen.
For at oprette forbindelse til en implementeret Cassandra-database kan du bruge cqlsh, kommandolinjeskallen og forespørge Cassandra ved hjælp af CQL fra din Kubernetes-klynge. Når den er godkendt, vil du være i stand til at indsende DDL-kommandoer for at oprette eller ændre tabeller osv. Og manipulere data med DML-instruktioner, såsom indsættelse og opdatering i CQL.
Hvad er det næste for Cassandra og Kubernetes?
Mens der er flere operatører tilgængelige for Apache Cassandra, har der været behov for en fælles operatør. Virksomheder, der er involveret i Cassandra-samfundet, såsom Sky, Orange, DataStax og Instaclustr, samarbejder om at etablere en fælles operatør for Apache Cassandra på Kubernetes. Denne samarbejdsindsats går sammen med de eksisterende open source-operatører, og målet er at give virksomheder og brugere en ensartet udskalningsstak til beregning og data.
Over tid skal overgangen til cloud-native applikationer også understøttes med cloud-native data. Dette vil stole på mere automatisering, drevet af værktøjer som Kubernetes. Ved at bruge Kubernetes og Cassandra sammen kan du gøre din tilgang til dataskyeregnet.
Hvis du vil vide mere om Cassandra og Kubernetes, skal du besøge //www.datastax.com/dev/kubernetes. For mere information om kørsel af Cassandra i skyen, se DataStax Astra.
Patrick McFadin er direktør for udviklerrelationer hos DataStax, hvor han leder et team dedikeret til at gøre brugere af Apache Cassandra succesrige. Han har også arbejdet som chefevangelist for Apache Cassandra og konsulent for DataStax, hvor han hjalp med at opbygge nogle af de største og spændende implementeringer i produktionen. Tidligere end DataStax var han chefarkitekt hos Hobsons og Oracle DBA / udvikler i over 15 år.
—
New Tech Forum giver et sted at udforske og diskutere nye virksomhedsteknologier i hidtil uset dybde og bredde. Valget er subjektivt baseret på vores valg af de teknologier, som vi mener er vigtige og af største interesse for læserne. accepterer ikke markedsføringssikkerhed til offentliggørelse og forbeholder sig retten til at redigere alt bidraget indhold. Send alle forespørgsler til [email protected].
