Konteineri ir kļuvuši arvien populārāki izstrādātājiem, kuri vēlas izvietot lietojumprogrammas mākonī. Lai pārvaldītu šīs jaunās lietojumprogrammas, Kubernetes ir kļuvis par de facto konteineru orķestrēšanas standartu. Kubernetes ļauj izstrādātājiem veidot izplatītas lietojumprogrammas, kas automātiski elastīgi mērogojas atkarībā no pieprasījuma.
Kubernetes tika izstrādāts, lai bez piepūles izvietotu, mērogotu un pārvaldītu bezvalstnieku lietojumprogrammu slodzes ražošanā. Runājot par valstspiederīgiem, mākoņdatiem datiem, ir vajadzīga vienāda izvietošanas un mērogošanas vienkāršība.
Izplatītās datubāzēs Cassandra ir pievilcīgs izstrādātājiem, kuri zina, ka viņiem būs jāpaplašina savi dati - tā nodrošina pilnīgi kļūdām tolerantu datu bāzi un datu pārvaldības pieeju, kas var darboties vienādi vairākās vietās un mākoņpakalpojumos. Tā kā visi Kasandras mezgli ir vienādi un katrs mezgls spēj apstrādāt lasīšanas un rakstīšanas pieprasījumus, Kasandras modelī nav viena kļūmes punkta. Dati tiek automātiski atkārtoti starp kļūmes zonām, lai novērstu viena gadījuma zaudēšanu, kas ietekmē lietojumprogrammu.
Kasandras savienošana ar Kubernetes
Loģisks nākamais solis ir Kasandras un Kubernetes lietošana kopā. Galu galā, ja izplatīta datu bāze darbojas kopā ar izplatītu lietojumprogrammu vidi, ir vieglāk iegūt datus un lietojumprogrammu darbības tuvu viena otrai. Tas ne tikai novērš latentumu, bet arī var uzlabot mēroga veiktspēju.
Lai to panāktu, tas nozīmē saprast, kura sistēma ir atbildīga. Kasandrai jau ir tāda veida kļūdu tolerance un mezglu izvietojums, ko Kubernetes var nodrošināt, tāpēc ir svarīgi zināt, kura sistēma ir atbildīga par lēmumu pieņemšanu. To panāk, izmantojot Kubernetes operatoru.
Operatori automatizē sarežģītāku lietojumprogrammu ieviešanu un pārvaldību, kurām nepieciešama domēna informācija un kurām ir nepieciešama mijiedarbība ar ārējām sistēmām. Kamēr operatori nav izstrādāti, valstiski lietojami lietojumprogrammu komponenti, piemēram, datu bāzes gadījumi, novedēja komandām radīja papildu atbildību, jo viņiem bija jāveic manuāls darbs, lai viņu instances sagatavotos un darbotos valstiski.
Kasandrai ir vairāki operatori, kurus izstrādājusi Kasandras kopiena. Šajā piemērā mēs izmantosim cass-operator, kuru DataStax ir izveidojis un atvēris. Tas atbalsta atvērtā koda Kubernetes, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) un Pivotal Container Service (PKS), tāpēc varat izmantot Kubernetes pakalpojumu, kas vislabāk atbilst jūsu videi.
Cass operatora instalēšana savā Kubernetes klasterī ir vienkāršs process, ja jums ir pamatzināšanas par Kubernetes klastera palaišanu. Kad jūsu Kubernetes kopa ir autentificēta, izmantojot kubectl, Kubernetes kopas komandrindas rīku un jūsu Kubernetes mākoņa instance (neatkarīgi no tā, vai tā ir atvērtā pirmkoda Kubernetes, GKE, EKS vai PKS) ir pievienota vietējai mašīnai, varat sākt lietot kas operatora konfigurācijas YAML faili jūsu kopai.
Kases operatora definīciju iestatīšana
Nākamais posms ir kasešu operatora manifesta, krātuves klases un datu centra definīciju piemērošana Kubernetes kopai.
Ātra piezīme par datu centra definīciju. Tas ir balstīts uz Kasandrā izmantotajām definīcijām, nevis atsauci uz fizisko datu centru.
Hierarhija tam ir šāda:
- Mezgls attiecas uz datorsistēmu, kurā darbojas Kasandras instance. Mezgls var būt fizisks resursdators, mašīnas gadījums mākonī vai pat Docker konteiners.
- Plaukts attiecas uz Kasandras mezglu kopu blakus viens otram. Plaukts var būt fizisks plaukts, kurā ir mezgli, kas savienoti ar kopēju tīkla slēdzi. Tomēr mākoņu izvietošanā plaukts bieži attiecas uz mašīnu eksemplāru kopumu, kas darbojas tajā pašā pieejamības zonā.
- Datu centrs attiecas uz loģisko plauktu kolekciju, kas parasti dzīvo vienā ēkā un ir savienota ar uzticamu tīklu. Mākoņu izvietošanā datu centri parasti kartē mākoņu reģionu.
- Klasteris attiecas uz datu centru kolekciju, kas atbalsta to pašu lietojumprogrammu. Kasandras kopas var darboties vienā mākoņa vidē vai fiziskā datu centrā, vai arī tās var sadalīt vairākās vietās, lai nodrošinātu lielāku noturību un samazinātu latentumu
Tagad mēs esam apstiprinājuši savas nosaukšanas konvencijas, ir pienācis laiks izveidot definīcijas. Mūsu piemērā tiek izmantots GKE, taču process ir līdzīgs citiem Kubernetes dzinējiem. Ir trīs pakāpieni.
1. solis
Pirmkārt, mums jāpalaiž komanda kubectl, kas atsaucas uz YAML konfigurācijas failu. Tas attiecas uz kases operatora manifesta definīcijas pievienotajam Kubernetes kopam. Manifesti ir API objektu apraksti, kas apraksta vēlamo objekta stāvokli, šajā gadījumā jūsu Kasandras operatoru. Pilnu versijai raksturīgo manifestu komplektu skatiet šajā GitHub lapā.
Šis ir kubectl komandas piemērs GKE mākonim, kurā darbojas Kubernetes 1.16:
kubectl create -f //raw.githubusercontent.com/datastax/cass-operator/v1.3.0/docs/user/cass-operator-manifests-v1.16.yaml
2. solis
Nākamajā komandā kubectl tiek izmantota YAML konfigurācija, kas nosaka krātuves Cassandra mezgliem izmantojamos krātuves iestatījumus. Kubernetes izmanto StorageClass resursu kā abstrakcijas slāni starp pākstīm, kurām nepieciešama pastāvīga krātuve, un fiziskajiem krātuves resursiem, ko var nodrošināt konkrēta Kubernetes kopa. Piemērā kā krātuves veids tiek izmantots SSD. Plašākas iespējas skatiet šajā GitHub lapā. Tālāk ir sniegta tiešā saite uz YAML, kas tiek lietots krātuves konfigurācijā.
apiVersion: storage.k8s.io/v1veids: StorageClass
metadati:
nosaukums: servera krātuve
nodrošinātājs: kubernetes.io/gce-pd
parametri:
tips: pd-ssd
replikācijas tips: nav
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Dzēst
3. solis
Visbeidzot, atkal izmantojot kubectl, mēs izmantojam YAML, kas nosaka mūsu Cassandra Datacenter.
# Darbam ar 3 k8s darba ņēmēju mezgliem ar 1 kodolu / 4 GB RAM# Dokumentus katram parametram skatiet blakus esošajā piemērā-cassdc-full.yaml
apiVersion: cassandra.datastax.com/v1beta1
veids: CassandraDatacenter
metadati:
nosaukums: dc1
spec:
clusterName: kopa1
servera tips: kasandra
serverVersion: "3.11.6"
managementApiAuth:
nedrošs: {}
izmērs: 3
storageConfig:
cassandraDataVolumeClaimSpec:
storageClassName: servera krātuve
accessModes:
- ReadWriteOnce
resursi:
pieprasījumi:
uzglabāšana: 5Gi
config:
cassandra-yaml:
autentifikators: org.apache.cassandra.auth.PasswordAuthenticator
autorizētājs: org.apache.cassandra.auth.CassandraAuthorizer
role_manager: org.apache.cassandra.auth.CassandraRoleManager
jvm-options:
initial_heap_size: "800 miljoni"
max_heap_size: "800M"
Šis piemērs YAML ir paredzēts atvērtā pirmkoda Apache Cassandra 3.11.6 attēlam ar trim mezgliem vienā statīvā Kubernetes kopā. Šeit ir tiešā saite. Šajā GitHub lapā ir pilns datu bāzei raksturīgu datu centru konfigurāciju komplekts.
Šajā brīdī jūs varēsiet apskatīt jūsu izveidotos resursus. Tie būs redzami jūsu mākoņa konsolē. Piemēram, Google mākoņa konsolē varat noklikšķināt uz cilnes Klasteri, lai redzētu, kas darbojas, un apskatītu darba slodzes. Tās ir izvietojamas skaitļošanas vienības, kuras var izveidot un pārvaldīt Kubernetes kopā.
Lai izveidotu savienojumu ar pašu izvietoto Cassandra datu bāzi, varat izmantot cqlsh, komandrindas čaulu un vaicāt Cassandra, izmantojot CQL savā Kubernetes klasterī. Pēc autentifikācijas jūs varēsiet iesniegt DDL komandas, lai izveidotu vai mainītu tabulas utt., Kā arī manipulēt ar datiem, izmantojot DML instrukcijas, piemēram, ievietot un atjaunināt CQL.
Kas notiks tālāk Kasandrai un Kubernetei?
Lai gan Apache Cassandra ir pieejami vairāki operatori, ir bijusi vajadzība pēc kopēja operatora. Kasandras kopienā iesaistītie uzņēmumi, piemēram, Sky, Orange, DataStax un Instaclustr sadarbojas, lai izveidotu kopēju Apache Cassandra operatoru Kubernetes. Šie sadarbības centieni notiek līdzās esošajiem atvērtā pirmkoda operatoriem, un to mērķis ir nodrošināt uzņēmumiem un lietotājiem konsekventu skaitļošanas un datu paplašināšanas paketi.
Laika gaitā pāreja uz mākoņa vietējām lietojumprogrammām būs jāatbalsta arī ar mākoņa vietējiem datiem. Tas paļausies uz vairāk automatizācijas, ko vada tādi rīki kā Kubernetes. Izmantojot Kubernetes un Cassandra kopā, varat izmantot savu pieeju datu mākonim.
Lai uzzinātu vairāk par Kasandru un Kubernetes, lūdzu, apmeklējiet vietni //www.datastax.com/dev/kubernetes. Lai iegūtu papildinformāciju par Cassandra palaišanu mākonī, skatiet DataStax Astra.
Patriks Makfadins ir izstrādātāju attiecību viceprezidents DataStax, kur viņš vada komandu, kuras uzdevums ir panākt Apache Cassandra lietotāju panākumus. Viņš ir strādājis arī kā Apache Cassandra galvenais evaņģēlists un DataStax konsultants, kur viņš palīdzēja izveidot dažus no lielākajiem un aizraujošākajiem ražošanas izvietojumiem. Pirms DataStax viņš bija galvenais arhitekts Hobsons un vairāk nekā 15 gadus Oracle DBA / izstrādātājs.
—
Jauno tehnoloģiju forums nodrošina vietu, kur bezprecedenta dziļumā un plašumā izpētīt un pārrunāt topošās uzņēmuma tehnoloģijas. Izvēle ir subjektīva, balstoties uz mūsu izvēlētajām tehnoloģijām, kuras, mūsuprāt, ir svarīgas un interesē lasītājus. nepieņem mārketinga nodrošinājumu publicēšanai un patur tiesības rediģēt visu ieguldīto saturu. Nosūtiet visus jautājumus uz [email protected].
