Programiranje

Kako voditi Cassandro in Kubernetes skupaj

Posode postajajo vse bolj priljubljene pri razvijalcih, ki želijo aplikacije namestiti v oblak. Za upravljanje teh novih aplikacij je Kubernetes dejansko postal standard za orkestracijo zabojnikov. Kubernetes razvijalcem omogoča izdelavo porazdeljenih aplikacij, ki se samodejno elastično prilagajajo glede na povpraševanje.

Kubernetes je bil razvit za enostavno uvajanje, spreminjanje in upravljanje delovnih obremenitev aplikacij brez državljanstva v proizvodnji. Ko gre za podatke, ki so naravni v oblaku, je bila potrebna enaka enostavnost uvajanja in obsega.

V porazdeljenih zbirkah podatkov je Cassandra privlačna za razvijalce, ki vedo, da bodo morali svoje podatke razširiti - zagotavlja popolnoma odporno bazo podatkov in pristop upravljanja podatkov, ki lahko delujeta enako na več lokacijah in v oblačnih storitvah. Ker so vsa vozlišča v Cassandri enaka in je vsako vozlišče sposobno obdelovati zahteve za branje in pisanje, v modelu Cassandra ni nobene točke okvare. Podatki se samodejno podvajajo med območji okvar, da se prepreči izguba posameznega primerka, ki vpliva na aplikacijo.

Povezovanje Kasandre s Kubernetesom

Logičen naslednji korak je uporaba Cassandre in Kubernetesa skupaj. Konec koncev, če distribuirana baza podatkov deluje skupaj z distribucijskim okoljem aplikacij, je lažje, da se podatki in aplikacije izvajajo blizu drug drugega. Ne samo, da se s tem izognemo latenci, lahko tudi izboljšamo zmogljivost v obsegu.

Če pa to dosežemo, pomeni razumeti, kateri sistem je odgovoren. Cassandra že ima takšno odpornost na napake in postavitev vozlišč, ki jih lahko zagotovi Kubernetes, zato je pomembno vedeti, kateri sistem je odgovoren za odločanje. To dosežemo z uporabo Kubernetesovega operaterja.

Operaterji avtomatizirajo postopek uvajanja in upravljanja bolj zapletenih aplikacij, ki zahtevajo podatke o domeni in potrebujejo interakcijo z zunanjimi sistemi. Dokler niso bili razviti operaterji, so komponente aplikacij s stanjem, kot so primerki baze podatkov, vodile do dodatnih odgovornosti za ekipe devops, saj so se morale ročno ukvarjati s pripravljanjem in delovanjem primerkov.

Za Cassandro obstaja več operaterjev, ki jih je razvila skupnost Cassandra. Za ta primer bomo uporabili cass-operator, ki ga je sestavil in odprl vir DataStax. Podpira odprtokodni Kubernetes, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) in Pivotal Container Service (PKS), tako da lahko uporabite storitev Kubernetes, ki najbolj ustreza vašemu okolju.

Namestitev cass-operatorja v lastno gručo Kubernetes je preprost postopek, če imate osnovno znanje o vodenju gruče Kubernetes. Ko je vaša gruča Kubernetes preverjena z uporabo kubectl, orodja ukazne vrstice grozda Kubernetes in vašega primerka oblaka Kubernetes (ne glede na to, ali je odprtokodni Kubernetes, GKE, EKS ali PKS) povezan z lokalnim računalnikom, lahko začnete uporabljati cass- datoteke YAML konfiguracije operaterja v vašo gručo.

Nastavitev definicij vašega cass-operatorja

Naslednja faza je uporaba opredelitev za manifest cass-operatorja, razred pomnilnika in podatkovni center za gručo Kubernetes.

Kratka opomba o definiciji podatkovnega centra. To temelji na definicijah, uporabljenih v Cassandri, in ne na sklicevanju na fizični podatkovni center.

Hierarhija tega je naslednja:

  • Vozlišče se nanaša na računalniški sistem, ki izvaja primerek Cassandre. Vozlišče je lahko fizični gostitelj, primerek stroja v oblaku ali celo Dockerjev vsebnik.
  • Stojalo se nanaša na niz vozlišč Cassandra blizu drugega. Stojalo je lahko fizično stojalo, ki vsebuje vozlišča, povezana s skupnim omrežnim stikalom. Pri uvajanju v oblaku pa se stojalo pogosto nanaša na zbirko primerkov računalnika, ki se izvajajo v istem območju razpoložljivosti.
  • Podatkovni center se nanaša na zbirko logičnih nosilcev, ki običajno prebivajo v isti stavbi in so povezani z zanesljivim omrežjem. Pri uvajanju v oblaku se podatkovni centri praviloma preslikajo v oblačno regijo.
  • Grozd se nanaša na zbirko podatkovnih centrov, ki podpirajo isto aplikacijo. Grozdi Cassandra lahko delujejo v enem samem okolju oblaka ali fizičnem podatkovnem centru ali pa se razdelijo na več lokacij za večjo odpornost in manjšo zakasnitev

Zdaj smo potrdili svoje konvencije o poimenovanju, čas je, da določimo definicije. Naš primer uporablja GKE, vendar je postopek podoben za druge motorje Kubernetes. Obstajajo trije koraki.

Korak 1

Najprej moramo zagnati ukaz kubectl, ki se sklicuje na konfiguracijsko datoteko YAML. To uporablja definicije manifesta cass-operatorja za povezano gručo Kubernetes. Manifesti so opisi objektov API, ki opisujejo želeno stanje predmeta, v tem primeru vašega operaterja Cassandra. Za celoten nabor manifestov, specifičnih za različico, si oglejte to stran GitHub.

Tu je primer ukaza kubectl za oblak GKE, ki izvaja Kubernetes 1.16:

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

2. korak

Naslednji ukaz kubectl uporabi konfiguracijo YAML, ki določa nastavitve pomnilnika za vozlišča Cassandra v gruči. Kubernetes uporablja vir StorageClass kot abstrakcijski sloj med stroji, ki potrebujejo trajno shrambo, in fizičnimi viri pomnilnika, ki jih lahko zagotovi določena skupina Kubernetes. Primer uporablja SSD kot vrsto pomnilnika. Za več možnosti glejte to stran GitHub. Spodaj je neposredna povezava do YAML, uporabljene v konfiguraciji pomnilnika:

apiVersion: storage.k8s.io/v1

vrsta: StorageClass

metapodatki:

ime: strežnik-pomnilnik

provizor: kubernetes.io/gce-pd

parametri:

vrsta: pd-ssd

vrsta replikacije: nobena

volumeBindingMode: WaitForFirstConsumer

reclaimPolicy: Izbriši

3. korak

Na koncu znova uporabimo kubectl in uporabimo YAML, ki definira naš Cassandra Datacenter.

# Velikost za delo na 3 k8s delavskih vozliščih z 1 jedrom / 4 GB RAM-a

# Glejte sosednji primer-cassdc-full.yaml za dokumente za vsak parameter

apiVersion: cassandra.datastax.com/v1beta1

vrsta: CassandraDatacenter

metapodatki:

ime: dc1

specifikacija:

clusterName: cluster1

serverType: cassandra

serverVersion: "3.11.6"

managementApiAuth:

negotovo: {}

velikost: 3

storageConfig:

cassandraDataVolumeClaimSpec:

storageClassName: pomnilnik strežnika

accessModes:

- ReadWriteOnce

viri:

zahteve:

shranjevanje: 5Gi

config:

cassandra-yaml:

avtentifikator: org.apache.cassandra.auth.PasswordAuthenticator

pooblastilo: org.apache.cassandra.auth.CassandraAuthorizer

role_manager: org.apache.cassandra.auth.CassandraRoleManager

jvm-options:

začetna_heap_size: "800M"

max_heap_size: "800M"

Ta primer YAML je za odprtokodno sliko Apache Cassandra 3.11.6 s tremi vozlišči na enem stojalu v gruči Kubernetes. Tukaj je neposredna povezava. Na tej strani GitHub je celoten nabor konfiguracij podatkovnih središč, specifičnih za zbirko podatkov.

Na tej točki si boste lahko ogledali vire, ki ste jih ustvarili. Ti bodo vidni v vaši oblačni konzoli. V Google Cloud Console lahko na primer kliknete zavihek Grozdi, vidite, kaj se izvaja, in si ogledate delovne obremenitve. Gre za razmestljive računalniške enote, ki jih je mogoče ustvariti in upravljati v gruči Kubernetes.

Če se želite povezati z razmeščeno bazo podatkov Cassandra, lahko uporabite cqlsh, lupino ukazne vrstice in poizvedujete Cassandro s pomočjo CQL znotraj vaše gručice Kubernetes. Po preverjanju pristnosti boste lahko oddali ukaze DDL za ustvarjanje ali spreminjanje tabel itd. In podatke obdelali z navodili DML, kot sta vstavljanje in posodobitev v CQL.

Kaj sledi za Cassandro in Kubernetes?

Čeprav je za Apache Cassandra na voljo več operaterjev, obstaja potreba po skupnem operaterju. Podjetja, ki sodelujejo v skupnosti Cassandra, kot so Sky, Orange, DataStax in Instaclustr, sodelujejo pri vzpostavitvi skupnega operaterja Apache Cassandra na Kubernetesu. To prizadevanje poteka skupaj z obstoječimi odprtokodnimi operaterji, cilj pa je podjetjem in uporabnikom zagotoviti skladen obseg zmanjšanja za izračune in podatke.

Sčasoma bo treba prehod na aplikacije, ki izvirajo iz oblaka, podpreti tudi s podatki v izvirnem oblaku. To bo temeljilo na večji avtomatizaciji, ki jo poganjajo orodja, kot je Kubernetes. Če skupaj uporabljate Kubernetes in Cassandro, se lahko približate podatkovnim oblakom.

Če želite izvedeti več o Cassandri in Kubernetesu, obiščite //www.datastax.com/dev/kubernetes. Za več informacij o zagonu Cassandre v oblaku si oglejte DataStax Astra.

Patrick McFadin je podpredsednik odnosov z razvijalci pri DataStaxu, kjer vodi ekipo, ki je namenjena uspešnemu uporabnikom Apache Cassandre. Delal je tudi kot glavni evangelist pri Apache Cassandri in svetovalec pri DataStaxu, kjer je pomagal zgraditi nekaj največjih in zanimivejših postavitev v proizvodnji. Pred DataStaxom je bil več kot 15 let glavni arhitekt pri Hobsonsu in Oracle DBA / razvijalec.

Forum New Tech ponuja prizorišče za raziskovanje in razpravo o nastajajoči podjetniški tehnologiji v globini in širini brez primere. Izbor je subjektiven in temelji na našem izboru tehnologij, za katere menimo, da so pomembne in najbolj zanimajo bralce. ne sprejema tržnih zavarovanj za objavo in si pridržuje pravico do urejanja celotne prispevane vsebine. Vsa vprašanja pošljite na [email protected]