Pokud chcete k poskytování služeb podniku používat Linux, musí být tyto služby zabezpečené, odolné a škálovatelné. Hezká slova, ale co tím myslíme?
„Zabezpečené“ znamená, že uživatelé mají přístup k požadovaným údajům, ať už jde o přístup pouze ke čtení nebo přístup k zápisu. Současně nejsou žádná data vystavena žádné straně, která nemá oprávnění je zobrazit. Zabezpečení je klamné: můžete si myslet, že máte vše chráněno, abyste později zjistili, že existují díry. Navrhování v oblasti zabezpečení od začátku projektu je mnohem snazší než pokus o jeho dodatečné vybavení později.
„Odolný“ znamená, že vaše služby tolerují selhání v infrastruktuře. Selhání může být řadič disku serveru, který již nemůže přistupovat k žádným diskům, což činí data nedostupnými. Nebo selhání může být síťový přepínač, který již neumožňuje komunikaci dvou nebo více systémů. V tomto kontextu je „jediný bod selhání“ nebo SPOF porucha, která nepříznivě ovlivňuje dostupnost služby. Odolná infrastruktura je infrastruktura bez SPOF.
„Škálovatelný“ popisuje schopnost systémů elegantně zvládat hroty poptávky. Také určuje, jak snadno lze v systémech provádět změny. Například přidání nového uživatele, zvýšení kapacity úložiště nebo přesun infrastruktury z Amazon Web Services do Google Cloud - nebo dokonce její přesun v rámci firmy.
Jakmile se vaše infrastruktura rozšíří za jeden server, existuje spousta možností pro zvýšení zabezpečení, odolnosti a škálovatelnosti. Podíváme se na to, jak byly tyto problémy tradičně vyřešeny a jaké nové technologie jsou k dispozici a mění tvář velkých aplikací.
Získejte více Linuxu!
Baví vás to, co čtete? Chcete více Linuxu a open source? Můžeme dodat, doslova! Přihlaste se k odběru Linux Format ještě dnes za výhodnou cenu. Můžete získat problémy s tiskem, digitální vydání nebo proč ne obojí? Dodáváme k vašim dveřím po celém světě za jednoduchý roční poplatek. Ať je váš život lepší a jednodušší, přihlaste se hned teď!
Abychom pochopili, co je dnes možné, je užitečné podívat se, jak se technologické projekty tradičně realizují. V dávných dobách - tedy před více než 10 lety - si podniky kupovaly nebo pronajímaly hardware, aby mohly provozovat všechny komponenty svých aplikací. Dokonce i relativně jednoduché aplikace, jako je web WordPress, mají více komponent. V případě WordPress je zapotřebí databáze MySQL spolu s webovým serverem, jako je Apache, a způsobem zacházení s kódem PHP. Takže by postavili server, nastavili Apache, PHP a MySQL, nainstalovali WordPress a mohli jít.
Celkově to fungovalo. Fungovalo to dostatečně dobře, že dnes stále existuje obrovské množství serverů nakonfigurovaných přesně tímto způsobem. Nebylo to ale dokonalé a dva z větších problémů byla odolnost a škálovatelnost.
Nedostatek odolnosti znamenal, že jakýkoli významný problém na serveru by měl za následek ztrátu služby. Je zřejmé, že katastrofické selhání by neznamenalo žádný web, ale také nebyl prostor pro provádění plánované údržby bez dopadu na web. I instalace a aktivace rutinní aktualizace zabezpečení pro Apache by vyžadovala několik sekundový výpadek webu.
Problém odolnosti byl do značné míry vyřešen vybudováním „klastrů s vysokou dostupností“. Princip spočíval v tom, že web měl spuštěny dva servery nakonfigurované tak, aby selhání jednoho z nich nevedlo k výpadku webu. Poskytovaná služba byla odolná, i když jednotlivé servery nebyly.
Abstraktní mrakySoučástí síly Kubernetes je abstrakce, kterou nabízí. Z pohledu vývojáře vyvíjejí aplikaci pro spuštění v kontejneru Docker. Dockeru nezajímá, zda běží na Windows, Linuxu nebo jiném operačním systému. Stejný kontejner Dockeru lze převzít z vývojářského MacBooku a bez jakýchkoli úprav jej spustit pod Kubernetes.
Samotná instalace Kubernetes může být jeden stroj. Mnoho výhod Kubernetes samozřejmě nebude k dispozici: nebude existovat žádné automatické škálování; je zde zjevný jediný bod selhání atd. Jako důkaz konceptu v testovacím prostředí však funguje.
Jakmile jste připraveni na produkci, můžete běžet interně nebo u poskytovatele cloudu, jako je AWS nebo Google Cloud. Poskytovatelé cloudu mají některé integrované služby, které pomáhají při spuštění Kubernetes, ale žádná z nich není pevná. Pokud se chcete pohybovat mezi Google, Amazonem a vlastní infrastrukturou, nastavíte Kubernetes a budete se pohybovat napříč. Žádná z vašich aplikací se nemusí nijak měnit.
A kde je Linux? Kubernetes běží na Linuxu, ale operační systém je pro aplikace neviditelný. Jedná se o významný krok ve vyspělosti a použitelnosti IT infrastruktur.
Efekt Slashdot
Problém se škálovatelností je trochu složitější. Řekněme, že váš web WordPress získává 1 000 návštěvníků měsíčně. Jednoho dne bude vaše firma zmíněna v rádiu 4 nebo snídani v televizi. Najednou získáte návštěvníky za více než měsíc za 20 minut. Všichni jsme slyšeli příběhy „zhroucení“ webů, a to je obvykle důvod: nedostatečná škálovatelnost.
Dva servery, které pomáhaly s odolností, dokázaly zvládnout vyšší pracovní vytížení, než by mohl jeden server sám, ale to je stále omezené. Za dva servery byste platili 100 procent času a oba většinou fungovaly perfektně. Je pravděpodobné, že by váš web mohl provozovat sám. Poté John Humphrys zmíní vaši firmu na Today a pro zvládnutí zátěže byste potřebovali 10 serverů - ale jen na pár hodin.
Lepším řešením problému s odolností i škálovatelností byl cloud computing. Nastavte instanci serveru nebo dva - malé servery, které spouštějí vaše aplikace - na Amazon Web Services (AWS) nebo Google Cloud, a pokud některá z instancí z nějakého důvodu selhala, automaticky se restartuje. Nastavte automatické škálování správně a když pan Humphrys způsobí, že se pracovní zátěž instancí vašeho webového serveru rychle zvýší, automaticky se spustí další instance serveru pro sdílení pracovní zátěže. Později, když úroky utichnou, jsou tyto další instance zastaveny a platíte pouze za to, co používáte. Perfektní … nebo ano?
I když je cloudové řešení mnohem flexibilnější než tradiční samostatný server, stále existují problémy. Aktualizace všech spuštěných cloudových instancí není přímá. Vývoj pro cloud má také problémy: laptop, který vývojáři používají, může být podobný instanci cloudu, ale není to stejné. Pokud se zavazujete k AWS, je migrace na Google Cloud složitým úkolem. A předpokládejme, že z jakéhokoli důvodu jednoduše nechcete předat své výpočty Amazonu, Googlu nebo Microsoftu?
Kontejnery se ukázaly jako prostředek k zabalení aplikací se všemi jejich závislostmi do jednoho balíčku, který lze spustit kdekoli. Kontejnery, jako je Docker, mohou běžet na laptopech vašich vývojářů stejným způsobem jako na cloudových instancích, ale správa flotily kontejnerů je s rostoucím počtem kontejnerů stále náročnější.
Odpovědí je orchestrace kontejnerů. Jedná se o významný posun zaměření. Předtím jsme se ujistili, že máme dostatek serverů, ať už fyzických nebo virtuálních, abychom zajistili, že můžeme obsluhovat pracovní zátěž. Použití automatického škálování poskytovatelů cloudu pomohlo, ale stále jsme řešili případy. Museli jsme ručně konfigurovat nástroje pro vyrovnávání zatížení, brány firewall, úložiště dat a další. Díky orchestraci kontejnerů je o vše (a mnohem více) postaráno. Specifikujeme požadované výsledky a naše nástroje pro orchestraci kontejnerů splňují naše požadavky. Určujeme, co chceme udělat, spíše než to, jak to chceme udělat.
Staňte se Kubernete
Kubernetes (ku-ber-net-eez) je dnes přední nástroj pro orchestraci kontejnerů a pochází od společnosti Google. Pokud někdo ví, jak provozovat rozsáhlou IT infrastrukturu, Google to dělá. Původem Kubernetes je Borg, interní projekt Google, který se stále používá ke spouštění většiny aplikací Google, včetně jeho vyhledávače, Gmailu, Map Google a dalších. Borg byl tajemstvím, dokud Google o tom v roce 2015 nepublikoval článek, ale díky článku bylo velmi zřejmé, že Borg byl hlavní inspirací pro Kubernetes.
Borg je systém, který spravuje výpočetní zdroje v datových centrech společnosti Google a udržuje aplikace Google, produkční i jiné, v provozu i přes selhání hardwaru, vyčerpání zdrojů nebo jiné problémy, které by jinak mohly způsobit výpadek. Dělá to pečlivým sledováním tisíců uzlů, které tvoří borgskou „buňku“ a na nich běžících kontejnerů, a spouštěním nebo zastavováním kontejnerů podle potřeby v reakci na problémy nebo kolísání zátěže.
Samotný Kubernetes se zrodil z iniciativy Google GIFEE („Google Infrastructure For Everyone Else“) a byl navržen jako přátelštější verze Borgu, která by mohla být užitečná i mimo Google. Byl darován nadaci Linux Foundation v roce 2015 vytvořením Cloud Native Computing Foundation (CNCF).
Kubernetes poskytuje systém, kterým „deklarujete“ své kontejnerové aplikace a služby, a zajišťuje, aby vaše aplikace běžely podle těchto prohlášení. Pokud vaše programy vyžadují externí prostředky, jako jsou úložiště nebo nástroje pro vyrovnávání zatížení, může je Kubernetes zřídit automaticky. Může škálovat vaše aplikace nahoru nebo dolů, aby držely krok se změnami v zatížení, a v případě potřeby mohou dokonce škálovat celý váš cluster. Komponenty vašeho programu ani nemusí vědět, kde běží: Kubernetes poskytuje interní služby pojmenování aplikací, aby se mohly připojit k „wp_mysql“ a být automaticky připojeny ke správnému prostředku. “
Konečným výsledkem je platforma, kterou lze použít ke spouštění vašich aplikací na jakékoli infrastruktuře, od jediného stroje přes lokální rack systémů až po cloudové flotily virtuálních strojů běžící na jakémkoli významném poskytovateli cloudu, všechny s použitím stejných kontejnerů a konfigurace. Kubernetes je poskytovatel-agnostik: spusťte jej kdekoli chcete.
Kubernetes je mocný nástroj a je nutně složitý. Než se dostaneme do přehledu, musíme představit některé pojmy používané v Kubernetes. Kontejnery spouštějí jednotlivé aplikace, jak je popsáno výše, a jsou seskupeny do podů. Pod je skupina úzce propojených kontejnerů, které jsou nasazeny společně na stejném hostiteli a sdílejí některé prostředky. Kontejnery v podu fungují jako tým: budou provádět související funkce, jako je kontejner aplikace a kontejner protokolování s konkrétním nastavením pro aplikaci.
Čtyři klíčové komponenty Kubernetes jsou API Server, Scheduler, Controller Manager a distribuovaná konfigurační databáze s názvem etcd. Server API je srdcem Kubernetes a funguje jako primární koncový bod pro všechny požadavky na správu. Ty mohou být generovány řadou zdrojů, včetně dalších komponent Kubernetes, jako je plánovač, správci prostřednictvím příkazového řádku nebo webových řídicích panelů a samotné kontejnerizované aplikace. Ověřuje požadavky a aktualizuje data uložená v etcd.
Plánovač určuje, na kterých uzlech různé pody poběží, s přihlédnutím k omezením, jako jsou požadavky na zdroje, jakákoli hardwarová nebo softwarová omezení, pracovní zátěž, termíny a další.
Správce řadičů monitoruje stav klastru a pokusí se spustit nebo zastavit lusky tak, jak je to nutné, prostřednictvím serveru API, aby se klastr dostal do požadovaného stavu. Spravuje také některá interní připojení a bezpečnostní funkce.
Každý uzel spouští proces Kubelet, který komunikuje se serverem API a spravuje kontejnery - obvykle pomocí Dockeru - a Kube-Proxy, který zpracovává síťové proxy a vyvažování zátěže v klastru.
Distribuovaný databázový systém etcd odvozuje svůj název od /atd složka v systémech Linux, která slouží k uložení informací o konfiguraci systému, plus přípona „d“, často používaná k označení procesu démona. Cílem etcd je ukládat data klíč - hodnota distribuovaným, konzistentním a odolným způsobem.
Server API uchovává všechna svá data o stavu v etcd a může současně spouštět mnoho instancí. Plánovač a správce řadiče mohou mít pouze jednu aktivní instanci, ale k určení, která běžící instance je hlavní, používá systém zapůjčení. To vše znamená, že Kubernetes může běžet jako vysoce dostupný systém bez jediného bodu selhání.
Dáme to dohromady
Jak tedy tyto komponenty v praxi použít? Následuje příklad nastavení webu WordPress pomocí Kubernetes. Pokud byste to chtěli udělat doopravdy, pravděpodobně byste použili předdefinovaný recept zvaný kormidelní tabulka. Jsou k dispozici pro řadu běžných aplikací, ale zde se podíváme na některé z kroků nezbytných k uvedení webu WordPress do provozu na Kubernetes.
Prvním úkolem je definovat heslo pro MySQL:
kubectl create secret generic mysql-pass --from-literal = password = YOUR_PASSWORD
kubectl bude mluvit s API serverem, který ověří příkaz a poté uloží heslo do etcd. Naše služby jsou definovány v souborech YAML a nyní potřebujeme nějaké trvalé úložiště pro databázi MySQL.
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pv-claims labels: app: wordpress spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi
Specifikace by měla být většinou vysvětlující. Pole názvu a štítků se používají k označení tohoto úložiště z jiných částí Kubernetes, v tomto případě našeho kontejneru WordPress.
Jakmile definujeme úložiště, můžeme definovat instanci MySQL a nasměrovat ji na předdefinované úložiště. Poté následuje definice samotné databáze. Dáme této databázi název a označení pro snadnou referenci v rámci Kubernetes.
Nyní potřebujeme další kontejner pro spuštění WordPress. Část specifikace nasazení kontejneru je:
druh: metadata nasazení: název: štítky wordpressu: aplikace: specifikace wordpress: strategie: typ: znovu vytvořit
Typ strategie „Znovu vytvořit“ znamená, že pokud se některý z kódů obsahujících aplikaci změní, budou spuštěné instance odstraněny a znovu vytvořeny. Mezi další možnosti patří možnost cyklického přepínání nových instancí a odebírání existujících instancí, což umožňuje službě pokračovat v běhu během nasazení aktualizace. Nakonec deklarujeme službu pro samotný WordPress, která zahrnuje kód PHP a Apache. Část souboru YAML deklarující toto je:
metadata: name: wordpress labels: app: wordpress spec: ports: - port: 80 selector: app: wordpress tier: frontend type: LoadBalancer
Všimněte si posledního řádku a definujte typ služby jako LoadBalancer. To dává Kubernetes pokyn, aby tuto službu zpřístupnil mimo Kubernetes. Bez této linky by to byla pouze interní služba „Pouze Kubernetes“. A to je vše. Kubernetes nyní použije tyto soubory YAML jako deklaraci toho, co je požadováno, a podle potřeby nastaví lusky, připojení, úložiště atd., Aby se cluster dostal do „požadovaného“ stavu.
To nutně byl pouze přehled na vysoké úrovni Kubernetes a mnoho podrobností a funkcí systému bylo vynecháno. Vysvětlili jsme autoscaling (oba lusky a uzly, které tvoří klastr), úlohy cron (spouštění kontejnerů podle plánu), Ingress (vyvažování zátěže HTTP, přepisování a odlehčení SSL), RBAC (řízení přístupu na základě role) , zásady sítě (firewall) a mnoho dalšího. Kubernetes je extrémně flexibilní a extrémně výkonný: pro každou novou IT infrastrukturu to musí být seriózní uchazeč.
Zdroje
Pokud nejste obeznámeni s Dockerem, začněte zde: https://docs.docker.com/get-started.
Zde je interaktivní výuka nasazení a škálování aplikace zde: https://kubernetes.io/docs/tutorials/kubernetes-basics.
Jak https://kubernetes.io/docs/setup/scratch, jak vytvořit cluster, najdete na https://kubernetes.io
Můžete hrát s bezplatným klastrem Kubernetes na https://tryk8s.com.
Nakonec můžete projít dlouhou technickou dokumentací s vynikajícím přehledem o tom, jak Google používá Borga a jak to ovlivnilo design Kubernetes zde: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.
Zjistěte více o Tiger Computing.
- Nejlepší cloudové úložiště roku 2022-2023 online: bezplatné, placené a obchodní možnosti
Baví vás to, co čtete? Chcete více Linuxu a open source? Můžeme dodat, doslova! Přihlaste se k odběru Linux Format ještě dnes za výhodnou cenu. Můžete získat problémy s tiskem, digitální vydání nebo proč ne obojí? Dodáváme k vašim dveřím po celém světě za jednoduchý roční poplatek. Ať je váš život lepší a jednodušší, přihlaste se hned teď!
