Kontejnery jsou stále populárnější pro vývojáře, kteří chtějí nasadit aplikace v cloudu. Ke správě těchto nových aplikací se Kubernetes stal de facto standardem pro orchestraci kontejnerů. Kubernetes umožňuje vývojářům vytvářet distribuované aplikace, které se automaticky elasticky škálují v závislosti na poptávce.
Kubernetes byl vyvinut pro snadné nasazení, škálování a správu pracovních zátěží bezstavových aplikací v produkčním prostředí. Pokud jde o stavová data z cloudu, je potřeba stejného snadného nasazení a škálování.
V distribuovaných databázích je Cassandra lákavá pro vývojáře, kteří vědí, že budou muset škálovat svá data - poskytuje plně odolný přístup k chybám v databázi a správě dat, který může běžet stejným způsobem na více místech a cloudových službách. Jelikož jsou všechny uzly v Cassandře stejné a každý uzel je schopen zpracovávat požadavky na čtení a zápis, neexistuje v modelu Cassandra jediný bod selhání. Data se automaticky replikují mezi zónami selhání, aby se zabránilo ztrátě jedné instance ovlivňující aplikaci.
Připojení Cassandry k Kubernetesovi
Logickým dalším krokem je společné používání Cassandry a Kubernetes. Koneckonců, spuštění distribuované databáze spolu s prostředím distribuované aplikace usnadňuje, aby data a operace aplikací probíhaly blízko sebe. Tím se nejen vyhnete latenci, ale také to pomůže zlepšit výkon ve velkém.
K dosažení tohoto cíle však znamená pochopení, který systém má na starosti. Cassandra již má druh odolnosti proti chybám a umístění uzlů, které může Kubernetes dodat, takže je důležité vědět, který systém má na starosti rozhodování. Toho je dosaženo pomocí operátoru Kubernetes.
Operátoři automatizují proces nasazení a správy složitějších aplikací, které vyžadují informace specifické pro doménu a potřebují interakci s externími systémy. Dokud nebyly vyvinuty operátory, stavové aplikační komponenty, jako jsou instance databáze, vedly k dalším odpovědnostem devops týmů, protože musely provést manuální práci, aby své instance připravily a fungovaly stavovým způsobem.
Existuje několik operátorů pro Cassandru, které byly vyvinuty komunitou Cassandra. V tomto příkladu použijeme operátor cass, který byl sestaven a otevřen zdrojem DataStax. Podporuje open-source Kubernetes, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) a Pivotal Container Service (PKS), takže můžete použít službu Kubernetes, která nejlépe vyhovuje vašemu prostředí.
Instalace operátoru cass do vlastního clusteru Kubernetes je jednoduchý proces, pokud máte základní znalosti o spuštění clusteru Kubernetes. Jakmile je váš klastr Kubernetes ověřen, pomocí nástroje kubectl, nástroje příkazového řádku klastru Kubernetes a vaší cloudové instance Kubernetes (ať už je to Kubernetes s otevřeným zdrojovým kódem, GKE, EKS nebo PKS) připojen k místnímu počítači, můžete začít používat cass- konfigurace YAML souborů operátora do vašeho clusteru.
Nastavení definic operátorů kazety
Další fází je použití definic manifestu operátoru cass, třídy úložiště a datového centra na klastr Kubernetes.
Rychlá poznámka k definici datového centra. Toto je založeno na definicích použitých v Cassandře, spíše než na odkazu na fyzické datové centrum.
Hierarchie je následující:
- Uzel označuje počítačový systém, na kterém běží instance Cassandry. Uzlem může být fyzický hostitel, instance stroje v cloudu nebo dokonce kontejner Dockeru.
- Rack označuje skupinu uzlů Cassandra blízko sebe. Rack může být fyzický rack obsahující uzly připojené ke společnému síťovému přepínači. V cloudových nasazeních však rack často odkazuje na kolekci instancí strojů běžících ve stejné zóně dostupnosti.
- Datové centrum označuje soubor logických rozvaděčů, které obvykle sídlí ve stejné budově a jsou propojeny spolehlivou sítí. V cloudových nasazeních se datová centra obecně mapují do cloudové oblasti.
- Cluster označuje kolekci datových center, která podporují stejnou aplikaci. Clustery Cassandra mohou běžet v jednom cloudovém prostředí nebo fyzickém datovém centru, nebo mohou být distribuovány na více místech pro větší odolnost a sníženou latenci
Nyní jsme potvrdili naše konvence pojmenování, je čas nastavit definice. Náš příklad používá GKE, ale proces je podobný pro ostatní motory Kubernetes. Existují tři kroky.
Krok 1
Nejprve musíme spustit příkaz kubectl, který odkazuje na konfigurační soubor YAML. To aplikuje definice manifestu operátor kazety na připojený klastr Kubernetes. Manifesty jsou popisy objektů API, které popisují požadovaný stav objektu, v tomto případě vašeho operátora Cassandra. Kompletní sadu manifestů specifických pro verzi najdete na této stránce GitHub.
Zde je příklad příkazu kubectl pro cloud GKE se systémem Kubernetes 1.16:
kubectl create -f //raw.githubusercontent.com/datastax/cass-operator/v1.3.0/docs/user/cass-operator-manifests-v1.16.yaml
Krok 2
Další příkaz kubectl použije konfiguraci YAML, která definuje nastavení úložiště pro uzly Cassandra v klastru. Kubernetes používá prostředek StorageClass jako vrstvu abstrakce mezi lusky vyžadujícími trvalé úložiště a prostředky fyzického úložiště, které může poskytnout konkrétní klastr Kubernetes. Příklad používá jako typ úložiště SSD. Další možnosti najdete na této stránce GitHub. Tady je přímý odkaz na YAML použitý v konfiguraci úložiště níže:
apiVersion: storage.k8s.io/v1druh: StorageClass
metadata:
name: server-storage
poskytovatel: kubernetes.io/gce-pd
parametry:
typ: pd-ssd
typ replikace: žádný
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Smazat
Krok 3
Nakonec opět použijeme kubectl a použijeme YAML, který definuje naše Cassandra Datacenter.
# Velikost pro práci na uzlech pracovníků 3 k8s s 1 jádrem / 4 GB RAM# Viz sousední example-cassdc-full.yaml pro dokumenty pro každý parametr
apiVersion: cassandra.datastax.com/v1beta1
druh: CassandraDatacenter
metadata:
název: dc1
spec:
název_ clusteru: cluster1
typ serveru: cassandra
serverVersion: "3.11.6"
managementApiAuth:
nejistá: {}
velikost: 3
storageConfig:
cassandraDataVolumeClaimSpec:
storageClassName: server-storage
režimy přístupu:
- ReadWriteOnce
zdroje:
požadavky:
skladování: 5Gi
konfigurace:
cassandra-yaml:
ověřovatel: org.apache.cassandra.auth.PasswordAuthenticator
autorizátor: org.apache.cassandra.auth.CassandraAuthorizer
role_manager: org.apache.cassandra.auth.CassandraRoleManager
možnosti jvm:
initial_heap_size: "800M"
max_heap_size: "800M"
Tento příklad YAML je pro open-source obraz Apache Cassandra 3.11.6 se třemi uzly na jednom stojanu v klastru Kubernetes. Zde je přímý odkaz. Na této stránce GitHubu je kompletní sada konfigurací datových center specifických pro databázi.
V tomto okamžiku se budete moci podívat na zdroje, které jste vytvořili. Ty budou viditelné ve vaší cloudové konzole. Například v Google Cloud Console můžete kliknout na kartu Klastry, zobrazit, co běží, a podívat se na pracovní vytížení. Jedná se o nasaditelné výpočetní jednotky, které lze vytvořit a spravovat v klastru Kubernetes.
Chcete-li se připojit k samotné nasazené databázi Cassandra, můžete použít cqlsh, prostředí příkazového řádku a dotazovat se na Cassandru pomocí CQL z vašeho klastru Kubernetes. Po ověření budete moci odesílat příkazy DDL k vytváření nebo úpravám tabulek atd. A manipulovat s daty pomocí pokynů DML, jako je vložení a aktualizace v CQL.
Co bude dál pro Cassandru a Kubernetes?
I když je pro Apache Cassandra k dispozici několik operátorů, existuje potřeba společného operátora. Společnosti zapojené do komunity Cassandra, jako Sky, Orange, DataStax a Instaclustr, spolupracují na založení společného operátora pro Apache Cassandra na Kubernetes. Toto úsilí o spolupráci jde vedle stávajících operátorů open-source a cílem je poskytnout podnikům a uživatelům konzistentní škálovatelný zásobník pro výpočet a data.
V průběhu času bude muset být přechod na nativní cloudové aplikace podporován také nativními cloudovými daty. To se bude spoléhat na více automatizace, poháněné nástroji, jako je Kubernetes. Společným používáním Kubernetes a Cassandra můžete svůj přístup k nativním cloudovým datům.
Další informace o Cassandře a Kubernetes najdete na stránce //www.datastax.com/dev/kubernetes. Další informace o spuštění Cassandry v cloudu najdete v DataStax Astra.
Patrick McFadin je viceprezidentem pro vztahy s vývojáři ve společnosti DataStax, kde vede tým věnovaný tomu, aby uživatelé Apache Cassandra byli úspěšní. Pracoval také jako hlavní evangelista pro Apache Cassandra a konzultant pro DataStax, kde pomáhal budovat některé z největších a vzrušujících nasazení ve výrobě. Předtím, než pracoval ve společnosti DataStax, byl více než 15 let hlavním architektem společnosti Hobsons a vývojářem Oracle DBA / vývojář.
—
Nové technologické fórum poskytuje místo, kde můžete prozkoumat a diskutovat o nově vznikajících podnikových technologiích v nebývalé hloubce a šíři. Výběr je subjektivní, založený na našem výběru technologií, které považujeme za důležité a pro čtenáře nejzajímavější. nepřijímá marketingové materiály ke zveřejnění a vyhrazuje si právo upravovat veškerý přispěný obsah. Všechny dotazy zasílejte na [email protected].
