Kako zajedno voditi Cassandru i Kubernetes

Spremnici postaju sve popularniji za programere koji žele primijeniti aplikacije u oblaku. Za upravljanje tim novim aplikacijama Kubernetes je postao de facto standard za orkestraciju spremnika. Kubernetes omogućuje programerima izradu distribuiranih aplikacija koje se automatski elastično prilagođavaju, ovisno o potražnji.

Kubernetes je razvijen za naporno postavljanje, skaliranje i upravljanje radnim opterećenjima aplikacija bez državljanstva u proizvodnji. Kada je riječ o podacima koji su izvorni za oblak, postojala je potreba za istom lakoćom implementacije i razmjera.

U distribuiranim bazama podataka Cassandra je privlačna za programere koji znaju da će morati povećati svoje podatke - pruža bazu podataka i pristup upravljanju podacima koji su potpuno otporni na pogreške i koji se mogu izvoditi na isti način na više lokacija i usluga u oblaku. Budući da su svi čvorovi u Cassandri jednaki i svaki čvor može obrađivati ​​zahtjeve za čitanje i pisanje, u modelu Cassandra ne postoji niti jedna točka kvara. Podaci se automatski repliciraju između zona neuspjeha kako bi se spriječio gubitak jedne instance koja utječe na aplikaciju.

Povezivanje Cassandre s Kubernetesom

Sljedeći je logičan korak zajednička upotreba Cassandre i Kubernetesa. Napokon, dobivanje pokrenute distribuirane baze podataka zajedno sa okruženjem distribuiranih aplikacija olakšava da se podaci i radnje aplikacija odvijaju blizu jedan drugog. Ovo ne samo da izbjegava kašnjenje, već može poboljšati performanse na razini.

Međutim, postići to znači razumijevanje sustava koji je glavni. Cassandra već ima otpornost na greške i postavljanje čvorova koje Kubernetes može isporučiti, pa je važno znati koji je sustav zadužen za donošenje odluka. To se postiže korištenjem Kubernetes operatora.

Operateri automatiziraju proces implementacije i upravljanja složenijim aplikacijama koje zahtijevaju podatke specifične za domenu i trebaju interakciju s vanjskim sustavima. Dok operateri nisu razvijeni, komponente aplikacija sa statusom poput instanci baze podataka dovele su do dodatnih odgovornosti za devops timove, jer su morali poduzimati ručni rad kako bi svoje instance pripremili i pokrenuli na način koji omogućava stanje.

Postoji više operatora za Cassandru koje je razvila zajednica Cassandra. Za ovaj primjer koristit ćemo cass-operator koji je sastavio i otvorio ga je DataStax. Podržava Kubernetes otvorenog koda, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) i Pivotal Container Service (PKS), tako da možete koristiti Kubernetes uslugu koja najbolje odgovara vašem okruženju.

Instaliranje cass-operatora na vlastiti Kubernetes klaster jednostavan je postupak ako imate osnovno znanje o pokretanju Kubernetes klastera. Jednom kada se provjeri autentičnost vašeg Kubernetes klastera, koristeći kubectl, alat naredbenog retka klastera Kubernetes i vaša instanca Kubernetes oblaka (bilo da su Kubernetes otvorenog koda, GKE, EKS ili PKS) spojeni na vaš lokalni stroj, možete početi primjenjivati ​​cass- YAML datoteke konfiguracije operatora na vaš klaster.

Postavljanje definicija vašeg cass operatora

Sljedeća je faza primjena definicija za manifest cass-operatera, klasu pohrane i podatkovni centar na klaster Kubernetes.

Kratka napomena o definiciji podatkovnog centra. To se temelji na definicijama koje se koriste u Cassandri, a ne na referencama na fizički podatkovni centar.

Hijerarhija za to je sljedeća:

  • Čvor se odnosi na računalni sustav koji pokreće primjerak Cassandre. Čvor može biti fizički domaćin, instanca stroja u oblaku ili čak Docker spremnik.
  • Stalak se odnosi na niz Cassandrinih čvorova u blizini. Stalak može biti fizički stalak koji sadrži čvorove povezane na zajedničku mrežnu sklopku. Međutim, u implementacijama u oblaku stalak se često odnosi na zbirku instanci stroja koje se izvode u istoj zoni dostupnosti.
  • Podatkovni centar odnosi se na zbirku logičkih stalaka, koji se uglavnom nalaze u istoj zgradi i povezani su pouzdanom mrežom. U implementacijama u oblaku, podatkovni centri općenito mapiraju regiju oblaka.
  • Klaster se odnosi na zbirku podatkovnih centara koji podržavaju istu aplikaciju. Klasteri Cassandre mogu se izvoditi u jednom oblačnom okruženju ili fizičkom podatkovnom centru ili se distribuirati na više lokacija radi veće elastičnosti i smanjenog kašnjenja

Sada smo potvrdili svoje konvencije imenovanja, vrijeme je da postavimo definicije. Naš primjer koristi GKE, ali postupak je sličan za ostale Kubernetesove motore. Tri su koraka. 

Korak 1

Prvo, moramo pokrenuti kubectl naredbu koja upućuje na YAML konfiguracijsku datoteku. Ovo odnosi definicije manifesta cass-operatera na povezanu Kubernetesovu klasteru. Manifesti su opisi API-ja, koji opisuju željeno stanje objekta, u ovom slučaju vašeg operatora Cassandra. Kompletni skup manifesta specifičnih za verziju potražite na ovoj GitHub stranici.

Evo primjera naredbe kubectl za GKE oblak koji izvodi Kubernetes 1.16:

kubectl create -f //raw.githubusercontent.com/datastax/cass-operator/v1.3.0/docs/user/cass-operator-manifests-v1.16.yaml

Korak 2

Sljedeća naredba kubectl primjenjuje YAML konfiguraciju koja definira postavke pohrane koje će se koristiti za Cassandrine čvorove u klasteru. Kubernetes koristi StorageClass resurs kao sloj apstrakcije između mahuna kojima je potrebna trajna pohrana i fizičkih resursa za pohranu koje određeni Kubernetesov klaster može pružiti. Primjer koristi SSD kao vrstu pohrane. Za više opcija pogledajte ovu stranicu GitHub. Evo izravne veze na YAML primijenjen u konfiguraciji pohrane, u nastavku:

apiVersion: storage.k8s.io/v1

vrsta: StorageClass

metapodaci:

  naziv: poslužitelj-pohrana

pribavljač: kubernetes.io/gce-pd

parametri:

  tip: pd-ssd

  tip replikacije: nema

volumeBindingMode: WaitForFirstConsumer

reclaimPolicy: Izbriši

3. korak

Napokon, ponovno koristeći kubectl, primjenjujemo YAML koji definira naš Cassandra Datacenter.

# Veličine za rad na radnim čvorovima od 3 k8s s 1 jezgrom / 4 GB RAM-a

# Pogledajte susjedni primjer-cassdc-full.yaml za dokumente za svaki parametar

apiVersion: cassandra.datastax.com/v1beta1

vrsta: CassandraDatacenter

metapodaci:

  naziv: dc1

specifikacija:

  clusterName: cluster1

  serverType: cassandra

  serverVersion: "3.11.6"

  managementApiAuth:

    nesigurno: {}

  veličina: 3

  storageConfig:

    cassandraDataVolumeClaimSpec:

      storageClassName: poslužitelj-pohrana

      accessModes:

        - ReadWriteOnce

      resursi:

        zahtjevi:

          pohrana: 5Gi

  config:   

    kasandra-yaml:

      autentifikator: org.apache.cassandra.auth.PasswordAuthenticator

      ovlaštenik: org.apache.cassandra.auth.CassandraAuthorizer

      role_manager: org.apache.cassandra.auth.CassandraRoleManager

    jvm-opcije:

      Initial_heap_size: "800M"

      max_heap_size: "800M"

Ovaj je primjer YAML za sliku otvorenog koda Apache Cassandra 3.11.6, s tri čvora na jednom nosaču, u klasteru Kubernetes. Evo izravne poveznice. Na ovoj GitHub stranici nalazi se cjelovit set konfiguracija centara podataka specifičnih za bazu podataka.

U ovom ćete trenutku moći pogledati resurse koje ste stvorili. Oni će biti vidljivi na vašoj oblačnoj konzoli. Na primjer, u Google Cloud Consoleu možete kliknuti karticu Klasteri da vidite što se izvodi i pogledati opterećenja. To su računalne jedinice koje se mogu rasporediti i koje se mogu stvoriti i njima upravljati u Kubernetesovom klasteru.

Da biste se povezali s postavljenom bazom podataka Cassandra, možete koristiti cqlsh, ljusku naredbenog retka i upitati Cassandru pomoću CQL-a unutar vašeg Kubernetes klastera. Nakon provjere autentičnosti moći ćete predati DDL naredbe za stvaranje ili izmjenu tablica itd. I manipulirati podacima pomoću DML uputa, poput umetanja i ažuriranja u CQL.

Što slijedi za Cassandru i Kubernetesa?

Iako je za Apache Cassandra dostupno nekoliko operatora, postojala je potreba za zajedničkim operatorom. Tvrtke uključene u zajednicu Cassandra, poput Sky, Orange, DataStax i Instaclustr surađuju na uspostavljanju zajedničkog operatora za Apache Cassandra na Kubernetesu. Ovaj napor za suradnju ide zajedno s postojećim operaterima otvorenog koda, a cilj je pružiti poduzećima i korisnicima dosljedan stepen smanjenja za račune i podatke.

S vremenom će prelazak na aplikacije izvorne za oblak morati biti podržan i podacima izvornim za oblak. To će se osloniti na više automatizacije, vođene alatima poput Kubernetesa. Korištenjem Kubernetesa i Cassandre zajedno možete pristupiti pristupu oblaku podataka.

Da biste saznali više o Cassandri i Kubernetesu, posjetite //www.datastax.com/dev/kubernetes. Za više informacija o pokretanju Cassandre u oblaku pogledajte DataStax Astra. 

Patrick McFadin potpredsjednik je odnosa s razvojnim programerima u DataStaxu, gdje vodi tim posvećen uspjehu korisnika Apache Cassandre. Također je radio kao glavni evanđelist za Apache Cassandra i savjetnik za DataStax, gdje je pomogao u izgradnji nekih od najvećih i uzbudljivih implementacija u proizvodnji. Prije DataStaxa, bio je glavni arhitekt u Hobsonsu i Oracle DBA / programer više od 15 godina.

-

New Tech Forum pruža mjesto za istraživanje i raspravu o novonastaloj tehnologiji poduzeća u neviđenoj dubini i širini. Izbor je subjektivan, zasnovan na našem odabiru tehnologija za koje vjerujemo da su važne i da najviše zanimaju čitatelje. ne prihvaća marketinške kolaterale za objavljivanje i zadržava pravo uređivanja cjelokupnog sadržaja. Pošaljite sve upite na [email protected]